User tests: Successful: Unsuccessful:
Colleagues, by what principle are the link panels in the system section sorted?
I would prefer the SETUP and MANAGE panels to be the first.
I feel tension every time I open a panel and try to find the right panel somewhere in the middle of other panels. And if the screen is small, then you will have to search for the most popular panel by rewinding the page.
.
Let's place the SETUP and MANAGE panels first.
I marked with numbers how I would like to see the order. But, I may be inaccurate. The main thing is that I would like to see the SETUP and MANAGE the in first position.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_menus |
I have tested this item
✅ successfully on 47ec0e3Test is successful. The thing I don't know if it is a good idea to change the order due to personal preference. but that's not up to me to decide.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35027.
I started using J4 in combat mode. Creating a website for sales. For the necessary cases, I had to go very, very many times to the CMS system section. I will say that it is very inconvenient when the MANAGE block jumps and then is located somewhere in the middle of the screen.
Which order would you personally prefer?
I agree that the block jumping is annoying. Clicked wrong a couple of times myself, so I get your point. I don't have a personal preference regarding the order, that's up to the maintainers to decide. Maybe it is a better option to create a solution which prevent the jumping in total.
Every project has other requirements , especially during development The best solution for you, @korenevskiy woluld be an own backend menu so you can have your favourite menu items in the menu bar itself.
@dgrammatiko The masonry grid is build with Javascript which is loaded after the page load. That's why the jumping occurs. Is there a way to prevent the jumping? In the Atum template I see some references to probably a prior/fallback solution for the layout using CSS column-count. Why use JS as we can implement a CSS option? Hope you can help...
I have tested this item
✅ successfully on 47ec0e3
We assume require the authors of pull requests to provide only code they have tested. But the authors shall not mark tests for their own pull requests in the issue tracker, because these tests will not count. A PR needs 2 human tests by other people than the author.
Why use JS as we can implement a CSS option?
Not my decision, if you go back in the PR implementing it you'll see my comments against it. Also, there's no way to fix the jumping unless you add display none till the JS evaluates (which is a terrible way to fix it and shouldn't be done)
@dgrammatiko As long as we don'n have a clever solution, we are stuck with the jumping. Annoying, but not the biggest problem. @ricardo1709 please test so we have two human tests.
I have tested this item
✅ successfully on 47ec0e3We
assumerequire the authors of pull requests to provide only code they have tested. But the authors shall not mark tests for their own pull requests in the issue tracker, because these tests will not count. A PR needs 2 human tests by other people than the author.
@korenevskiy Sorry, my mistake. I haven't noticed it was a citation of @RickR2H 's test. To me it looked like it was your test at a first view.
This is for sure a UX issue but it will not get solved by resorting. Someone else might want another order and at the end of the day is is a question of personal preference. We decided to let it as it is.
@korenevskiy maybe start a discussion to find a clever way that suits all needs.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-08-03 15:36:46 |
Closed_By | ⇒ | rdeutz | |
Labels |
Added:
?
|
This is for sure a UX issue but it will not get solved by resorting. Someone else might want another order and at the end of the day is is a question of personal preference. We decided to let it as it is.
@korenevskiy maybe start a discussion to find a clever way that suits all needs.
Of course, there will always be someone who wants a different order.
I propose to vote.
No need to vote thats not how we do things - things will be even slower to develop
No need to vote thats not how we do things - things will be even slower to develop
The Masonry layout implies automatic placement depending on the height of the block. So that the lower border of the parent's space is aligned with the content.
Thus, the order of the blocks was imposed on us by the JS Masonry script. At your discretion. But in the cards there were blocks in which the number of elements is the same. Even they can't be swapped at our discretion. The JS script has its own logic.
I turned off Masonry. Sorted the blocks as the creator/maintainer of the sites.
As a result, it was possible to remove the block jumps when the page was loading.
Please test the PR
I have tested this item✅ successfully on 47ec0e3
Test is successful. The thing I don't know if it is a good idea to change the order due to personal preference. but that's not up to me to decide.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35027.