User tests: Successful: Unsuccessful:
Redo of Issue #21361.
Added Breadcrumb to menus in backend
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_menus |
Test successful, but not useful to me.
The word "test" is short... lot of my clients have longer Menu Item titles.
Some customers even have sub sub menu items
This will result in a very long breadcrumb in the backend.
Please do not merge this PR into J4.... or give me the possibility to disable this feature. It might be useful to others. But not for me.
Can you propose a better way of displaying the breadcrumbs?
Let's take it a step further. What is the need to display a full breadcrumb to every menu item on the list view and what kind of value is it adding by doing so? How is this an issue only for menu items and not other hierarchical data types (i.e. why not the full path for categories or tags)?
Both this issue and the original PR are very vague on why this is a needed improvement or even a good idea in general. They both right now are written in a "I think this way is better and you should accept it" way without really explaining why this way is better.
There is no need for me to display the breadcrumbs in Joomla Administrator.
It takes to much space on a mobile device.
Why propose a better way if there is no need for breadcrumbs to display on every menu item?
A better way for me is not to display the breadcrumbs. :-) (or have the option to disable it)
@VladikB for you first contribution to joomla,
Beside my personal opinion that the menu tree per menu item overloads the view you should use the Joomla API instead of directly querying the database. In your case you can use the menu framework to get the menu items instead calling your searchParentItem function.
Something like this should work: Factory::getApplication()->getMenu()->getItem($itemid);
On the other side you are creating the tree in the layout file, you shouldn't do this, you should do any preparation in the model.
I would change the model getItems function and add the tree to the object.
But as already mention I don't think that adding the tree brings any benefit to the view.
Let's get back to why this even became an idea that should be fixed.
What is the need to display a full breadcrumb to every menu item on the list view and what kind of value is it adding by doing so?
Here is my menu, I have no clue which menu item belongs to which parent:
Showing me the parent, will give me an idea of which menu item I need to pick to change.
How is this an issue only for menu items and not other hierarchical data types (i.e. why not the full path for categories or tags)?
I would argue that hierarchical data types in the Joomla backend are horrible to work with. So it is not only menus but it could use a better solution in many more places. Here is another example in editing a menu item:
Same goes for the category selector in the search tools:
Unless it is just me and everybody else thinks this is a normal way of working. Does this give a better insight as to the problem it tries to solve?
It takes to much space on a mobile device.
My other idea was we show the breadcrumbs the same way the selected item is shown below the menu option.
Definitely an issue for me with the filters
Oh and I forgot it also solved a big accessibility issue
The accessibility issue applied all the time
But... as you say it solves an issue when you apply filters.
Not only when you apply filters, also happens when your menu runs across multiple pages.
@brianteeman I am not fully understanding, adding these breadcrumbs solves an accessibility issue?
Yes it solves an issue. If you can only hear one line at a time it's not possible to get the context of a menu item. Showing the full path solves that.
Having the full path in the filters is a must fix and something I've groaned about on other products too (still not fixed there either last I looked). But that's not the focus here.
To me, the breadcrumb is really only needed on the main list view when:
To me it feels like there really should be a better way of displaying the tree information without repeating the parent labels on every line. Especially as it feels like to me it would turn into an information overload once you start getting 2 or 3 levels deep.
I agree with that as well. It's why I haven't submitted an a11y pr for it as I couldn't work out a nice look
I am no UX designer either. I guess if we move the path 1 line down, you have 3 lines of text which is a bit much as well.
Do you really need both the menu item type breadcrumb and the menu item path breadcrumb? Surely the menu item path is going to be more useful than the item type and in a game of picking and choosing I'd rather that in a similar display as what's used in the articles list than a (IMO) superfluous path that doesn't really give me much beneficial information on that screen.
That is an interesting thought. I do agree I barely ever look at the menu item type as the title of the menu is usually more descriptive to me. So replacing one with the other would make sense to me as well.
Actually the menu item type is important for beginners to understand what they are doing. Please do not remove that or at least add a symbol displaying if its an Article / Blog / List / Contact / Komponent...
I can imagine having the breadcrumbs in small size above the title, but with the possibility to turn off the information?
Labels |
Added:
?
|
That looks quite cluttered, maybe the Alias should be below too to have a better layout of the Informations.
And like that:
Alias: ....
Path: ....
Menuitem type: ....
That looks quite cluttered, maybe the Alias should be below too to have a better layout of the Informations.
And like that:
Alias: ....
Path: ....
Menuitem type: ....
Which will result in four rows per menu item:
Title
alias: ...
path: ...
menu item type: ...
Please replace /
by ›
as the latter indicates a beter forward motion then a forward slash.
›
is a Single right-pointing angle quotation mark
U+0203A
›
›
›
\203A
Which will result in four rows per menu item:
Title alias: ... path: ... menu item type: ...
Yes but if you look at the screenshot its probably better to have the four rows but not a cut off alias... we could give the Menu item type an own column?
Which will result in four rows per menu item:
Title alias: ... path: ... menu item type: ...
Yes but if you look at the screenshot its probably better to have the four rows but not a cut off alias... we could give the Menu item type an own column?
The cut off alias would be there without my changes too. It comes because the menu name is so long
Please also test this in RTL. ;)
What about using "ellipse" when it's getting to long and show the full line in a title on hover?
good or bad idea?
@coolcat-creations when is a breadcrumb too long?
On a mobile device (iPhone 5) the viewport is only 320px
Maybe the breadcrumbs should be more like a title line above ALL items that are below a parent instead of repeating itself over and over again. This would need some thinking how to code it when items are torn apart in the middle.
That would fail accessibility
Ok, I don't see a nice solution, maybe the design team has an idea...
I think, it's OK how it looks like now, I mean if it is accepted that alias and titles can break the line like they do, why shouldn't it be accepted with breadcrumb?
I was only thinking about improving the layout for Joomla 4 - now that we have a chance to do so...
Keep alias on the same line as the title. The same way it is done in every
other list screen. If we want to move it then do it in a separate PR
changing all views at once.
On Mon, Sep 9, 2019 at 7:06 AM VladikB notifications@github.com wrote:
I think, it's OK how it looks like now, I mean if it was accepted that
Alias can break the line like they do, why shouldn't it be aceepted with
breadcrumb?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/26187?email_source=notifications&email_token=AACZ7IOKI55ZSVXQU5ZE33LQIY35XA5CNFSM4IUHVBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HKC5I#issuecomment-529441141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACZ7IOLD3YDOMQ3AISSIYTQIY35XANCNFSM4IUHVBTA
.
--
They are in the same line, I just showed how it would look like if they weren't
I know, but with it being suggested, I wanted to squash it early because it
should be changed in all views if that is going to be seriously pursued
(don’t care either way where it ends up), and that goes far beyond the goal
of this PR.
On Mon, Sep 9, 2019 at 7:18 AM VladikB notifications@github.com wrote:
They are in the same line, I just showed how it would look like if they
weren't—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/26187?email_source=notifications&email_token=AACZ7IIRGZ4XFXXYTEF53ADQIY5JDA5CNFSM4IUHVBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HLEGA#issuecomment-529445400,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACZ7IKV3X2X6SZWETKDHALQIY5JDANCNFSM4IUHVBTA
.
--
Category | Administration com_menus | ⇒ | Administration com_menus Language & Strings |
So I added an option to turn on or to turn off the breadcrumbs now.
Shouldn't that be a global option somewhere else? For me "Page Display" options are for the Frontend... We have column display options in the tables asfaik
I have tested this item
I have tested this item
If the final output is expected as below then the test is successful.
If Menu Options > Show breadcrumbs is "ON" then showing the result as
Else if Menu Options > Show breadcrumbs is "OFF" then showing the result as
Please, can someone confirm what is the expected final output? Hard to understand from comments.
Adding the screenshots for above successful test
I have tested this item
I have tested this item
I have tested this item
The patch works, but it is not very clear, what this list indicates
I have tested this item
As Renuka said, it works correctly though I am not sure that way is the intended way
I have tested this item
As Renuka said, it works correctly though I am not sure that way is the intended way
Maybe someone can convince the accessibility team to test this
This can be closed and picked up in another PR if someone is interested as topic starter is no longer available.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-08-01 17:47:40 |
Closed_By | ⇒ | roland-d | |
Labels |
Added:
Conflicting Files
?
|
Views really shouldn’t be running database queries on their own accord
This is introducing a lot of database queries to this view