As far as design patterns are concerned, I have always felt that saving primary interactions for on-click events and using peripheral ones for on hover lends a more solid feel to any piece of element anywhere on the software scene.

I may be wrong on this but I think things should happen on a piece of software only when a voluntary , informed piece of action triggers them; in this case, a solid click. On-hover events should always trigger introductory actions that let the user have a peek into what is going to happen if he/she click.

There can be cases made for primary interactions being trigerred on hover; especially where the interaction concerns multiple handles to be trigerred. e.g. when 5-6 different menu-heads exist, navigating between them using clicks may seem a tiny bit tedious. But still the previous agreement puts up a very good fight in this case as well and has tilted balance in it's favour for most web applications (the good old menu bar:)).

Keeping primary interactions on hover may have the upper hand while considering "dazzle my eyes and blow up my mind" options, but since we are talking about usability over afternoon tea, I guess unobtrusive design that allows you to do what you want without coming in your way is what has the final laugh.

So I would suggest, you should consider keeping the unrolling of the massive menu on click rather than on hover. That takes care of the mobile problem as well.

Clink to all the beautiful things in our life ;)

As far as design patterns are concerned, I have always felt that saving primary interactions for on-click events and using peripheral ones for on hover lends a more solid feel to any piece of element anywhere on the software scene.

I may be wrong on this but I think things should happen on a piece of software only when a voluntary , informed piece of action triggers them; in this case, a solid click. On-hover events should always trigger introductory actions that let the user have a peek into what is going to happen if he/she click.

There can be cases made for primary interactions being triggered on hover; especially where the interaction concerns multiple handles to be triggered. e.g. when 5-6 different menu-heads exist, navigating between them using clicks may seem a tiny bit tedious. But still the previous agreement puts up a very good fight in this case as well and has tilted balance in it's favour for most web applications (the good old menu bar:)).

Keeping primary interactions on hover may have the upper hand while considering "dazzle my eyes and blow up my mind" options, but since we are talking about usability over afternoon tea, I guess unobtrusive design that allows you to do what you want without coming in your way is what has the final laugh.

So I would suggest, you should consider keeping the unrolling of the massive menu on click rather than on hover. That takes care of the mobile problem as well.

Clink to all the beautiful things in our life ;)