Right align level 1 menu items

[haPartnerships]

Hi

Is there a way to align the level 1 menu items to the right as opposed to the left of their level 0 parent item

context:

- A level 0 item with a long display text followed by an icon for the level 1 dropdown 

- the user moves the mouse towards the drop down icon and the level 1 menu appears

- the level 1 menu has items with short display names

- as the user moves the mouse from the icon to the sub-menu the sub-menu will disappear as they have left the parent menu item

(- if they moved the mouse along the parent item to the left then drop onto the sub-menu it is fine)

 

question:

can the sub-menu container be right aligned to the parent menu item so it effectively displays under the drop-down icon?

[Svetoslav Dimitrov]

Hello Matthew,

I can see why the current behavior of the Menu can cause issues and confusion with your customers. We have reviewed your request internally and I would like to ask for some feedback and share our observations.

Questions:

• The users can hover over any part of the Menu item to expand its children, not just the arrow. If we expose a setting for the alignment of the popup and a user hovers somewhere on the left part of the root menu item the same behavior will be experienced. Can you share some feedback on the topic of an alignment parameter that would be the best resolution?
• Do you think that expanding the width of the dropdown to match the width of the root item will be a good solution?
• We have an open feature request for the OpenOn and CloseOn parameters. Once they are exposed you will be able to set if the menu opens and closes on hover or on click. If you set the Menu to close on click your users will be able to navigate to the popup easily even if the popup has a smaller width than the root item. Do you like that solution?

Our observations:

In our opinion, the best robust solution for the behavior would be the OpenOn and CloseOn parameters.

Regards,
Svetoslav Dimitrov
Progress Telerik

[haPartnerships]

• The users can hover over any part of the Menu item to expand its children, not just the arrow. If we expose a setting for the alignment of the popup and a user hovers somewhere on the left part of the root menu item the same behavior will be experienced. Can you share some feedback on the topic of an alignment parameter that would be the best resolution?

 

I think there is an element of psychology (not that I am an expert by any means) in so much as if we provide a point of visual reference (i.e. the down arrow in this case) the user is more instinctively drawn to that arrow to activate the menu and thus the mouse pointer is *more likely*to be aligned to that side of the parent menu item - not exclusively but with a greater level of probability.

Also with a 'right of the screen' aligned menu a user is also more likely to be manoeuvring their mouse towards the top right of the screen from elsewhere and thus it is a natural feeling action to keep moving it right to hit the submenu. The current left aligned means that you need to re-engage the braincells at the last moment when the drop down appears to be able to make a sharp left turn to get to the drop down.

On a 'left of the screen' aligned main menu you naturally will hit the right side of the parent menu item first when manoeuvring the pointer and therefore a right aligned sub-menu will feel natural there too.

• Do you think that expanding the width of the dropdown to match the width of the root item will be a good solution?

This certainly would work but could look a little funky with a long parent menu item - say your menu logic changes the word 'login' to your username on authentication with a sub menu item 'logout' - there may be a long sub-menu box with little in it which may just aesthetically not work for your UI principles.

If there could be a full width transparent container which maintains the mouseover behaviour of the menu with the current 'sized by the content' sub-menu block that may work - but the option to right align would just (in my opinion) be aesthetically better.

• We have an open feature request for the OpenOn and CloseOn parameters. Once they are exposed you will be able to set if the menu opens and closes on hover or on click. If you set the Menu to close on click your users will be able to navigate to the popup easily even if the popup has a smaller width than the root item. Do you like that solution?

So that option is useful but for a modern fluid UI feel the automatic mouseover open/close behaviour is a really nice touch - clicking elsewhere to exit a menu seems a little outdated (although may be useful in some contexts).

 

Thinking a little more about it whilst writing this and being naïve as to the complexity for you to engineer it - I think my preferred outcome would be for:

A transparent submenu block the full width of the parent which can maintain the mouseover as you move the pointer from teh parent to the submenu items AND a simple css class to have the submenu itself (as it is currently rendered in a box which adapts to its contents width) left, mid or right aligned.

Hope that is in the slightest bit helpful!

[Svetoslav Dimitrov]

Hello Matthew,

I really appreciate the time and effort you spent on the provided feedback. I had a discussion between the UX/UI design team and the developers in our product team, let me share our thoughts:

Having a transparent submenu element that spans across the full width of the parent that maintains the mouseover, and a CSS class.

I can agree that this sounds reasonable, however, when we dug deeper into the implementation and the behavior it seems that it will be really hard to achieve a generic behavior. Let me elaborate:

• If we increase the width of the popup container to match the width of the item and make part of it transparent what would happen to the borders of the transparent part? This is a question that we could not give an answer to. 
• Add a second div that stands next to the actual popup that should trap the mouseover event and keep the popup open. This would work as expected only if the menu items in the popup do not have children themselves. If there is a second popup that must be opened that the transparent div might trap the events of the second child container. If we choose to remove the transparent div from the DOM if a second-level child container is visible we should implement it with JavaScript as Blazor does not give such control over the DOM tree. Using JavaScript is acceptable only when we have absolutely no other choice. Adding a second element would also require a brand new rendering for the Menu which will cause breaking changes that we will not be able to predict and provide solutions preemptively. 

The OnOpen and OnClose on click

The next step in the evolution of the Telerik Menu is to support mobile devices. In the mobile world, there is no concept of hover, everything must work on click. Based on the dire need for the ability to open and close the menu on click we would like to solve the behavior you are after with that ideally. This approach will remove all the questions and uncertainties from adding a second element or modifying the existing container. 

Let me know if this sounds reasonable for you and I would like to see if you have any opinion on our conclusions.

 

[haPartnerships]

That makes sense re the feasibility of implementation of a transparent div and alignment based solution.

Is there then a middle ground then where the onOpen and OnClose implementation is delivered alongside a simple left centre right align css class for the sub-menu (acknowledging the limitation that exists at present of the risk of losing focus as the mouse moves from parent to the child menu).

Interesting point you raise "In the mobile world, there is no concept of hover" that statement assumes a clear division between desktop and mobile which I am not sure exists anymore - I am currently using these blazor components in a MAUI hybrid application on a MS Surface windows 11 device with keyboard and mouse and also in tablet format using touch, a Galaxy fold 4 phone (small front screen and larger opened up screen) using touch, and also the galaxy fold 4 on the larger screen with a bt keyboard and mouse.

The adaptability in my mind needs to be to support click and hover seamlessly as you no longer really get to choose the target device format or the hardware (mouse / keyboard / touchscreen) and the user would appreciate the response from the components that they expect with touch or mouse.

 

[Svetoslav Dimitrov]

Hello Matthew,

We prepared a sample implementation of the menu items aligned to the right-hand side of the Menu, and you can see it from this REPL link. Can you check this out and get back to me if this is the desired result?