Merge menu items

[Mandily]

Currently the parent link of each section is a blank page. Sometimes the label is repeated underneath like in the products area. This can be confusing for users and leads to an extra click to access the ‘listings’ pages.

I’d like to streamline the menu by making the parent label of each menu section link to the listings page, and remove the first link from each sub menu list. This means that when the user clicks on the parent label to expand a section and select a link inside, they would also be loading the listings page in the process.

Please let me know your thoughts in the comments below.

[athal7]

👍

[alepore]

I'm not sure about this, the products and general settings pages have sometimes no direct relation with their sub items.
Why would i load the products index page if i want to edit taxonomies?

I'd prefer changing the "Products" parent labels to something like "Products and Taxons", or splitting products and taxonomies to different menus.

Also note that the general setting page is really not a "listing" page, it's just one of the many settings pages, probably on of the lesser-used ones on production sites :)

Your proposal makes sense for the promotion menu though, but that's because it's very specific and only contains promotions stuff, imho.

[tvdeyen]

+10000000000 for splitting taxonomies and products!

[dhonig]

I agree with splitting taxonomies and products, so long as it is not done in the awful way it was originally back in the early days, but maybe its that awful taxon editor still hurting me..
Taxons and Taxonomies should be a separate top level concern than products rather than being buried underneath a 'products' tab.

[alepore]

The "Taxon" submenu also has a bad name: i always rename it as "Products Ordering"

[athal7]

@alepore agreed re settings, maybe we don't require that all top level menus are clickable, just the ones that make sense to me. Also in favor of splitting products and taxons.

[Mandily]

Thanks for your comments on restructuring the IA. Those ideas will be helpful in reorganizing it in the future. In favour of doing it in small chunks, it's makes sense to first make it consistent so that it's easier to expand and is more intuitive for new users.

Taxonomies can be found in both products and settings. In future work, I'd like to remove it from the products menu and leave it in the settings. But let's save that conversation when we have a holistic view of the menu in a couple of issues.

For a visual of what's being proposed in this issue, see the image below. On the 'current' side, there's a few items that are black because they don't have specific pages tied to them. On the 'proposed' side you'll see I've removed the extra nav items and replaced them with their current child items from the left. The text in the parenthesis's are the actual content the link would lead to.

The second option would be to make all parent links exist solely to open their children like in the third 'less desirable' option below. It creates an extra step in accessing the listing pages, and also creates a sub menu in a couple of places that don't really need it. Based on how I see the menu functioning in the out of the box model, the first proposed solution looks the best to me.

What I'm wondering is - what custom menu items have you added that would/wouldn't fit into this model?

[tvdeyen]

Great proposal. I like the idea of removing clicks.

One possible menu item not fitting in this is grouping equal listings into on tab, like documents for instance.

Imaging two types of document listings, invoices and packing slips. Both of them are grouped under a documents section. The documents label has no direct relation to one the nested listings. And none of them is more important than the other, so just linking the main menu entry to one of the child listings is not an option IMO.

Another thing to consider is the possibility to directly reach one of the child pages. Especially under the settings tab.

Also, we should consider performance. If I have to load lots of records of a listing just to reach one of the child pages is not ideal. So, clicking "products" (all products load) then click "option types" is slower, in terms of database load, then toggling a folder and click the desired sub page.

I think this can be addressed by hovering the main menu items. But what gesture do we use on touch devices then?

[alepore]

what custom menu items have you added that would/wouldn't fit into this model?

I always use the main labels just to group similar things, for example:

I grouped all their custom resources together, and the client asked me to make another group for the homepage stuff, because it's easier for them.
That's why the "proposed menu" model doesn't fit for me.
I have sites with 15+ different custom resources pages and i'd like to have the flexibility to group them as i (or the client) want.

[Mandily]

@tvdeyen Instead of telling you of plans to implement a flyout in the next issue, I just went ahead and created it #505 I think that may help steer decisions made on this issue so I wanted to get it up now.

I see three options for the left nav structure/interaction model. (black = no page link, blue = page link) I see there being benefits to leaving it flexible because different sites have different needs, but I don't feel super comfortable creating a navigation with an inconsistent interaction model to do it.

What do you guys think would be best for Solidus as a whole?

[tvdeyen]

Thanks @Mandily for the fly out menu proposal. Really like the idea. I think option a is the best way to go, if, and only if, we also add the fly out menu. Then we have best of both worlds. Small consistent menu and direct access of "children" (or other group members)

👍

[Mandily]

After chatting with @Sinetheta I think the best way to go is how Wordpress and the current menu in Solidus seems to be designed.

Duplicate items like products at a parent and child menu, and clean up the labels a bit so that they're distinctly different than their parents. So 'products' is the parent and 'product listings' is the child. The flyout helps users access items below quickly, so we don't have to worry about the extra click so much.

@tvdeyen This would mean that the first child item would be displayed when the user clicks on the parent. Displaying the last viewed page, or a blank page just doesn't make sense in this situation.

In the case where an item would only have one child, we make the parent the link instead of creating a sub menu. So the Orders and Reports page wouldn't have a child item.

This has been a good conversation even to arrive back at the original design. At least now I know the reasons behind it! Thanks guys!

Is anyone against keeping the current structure/model and updating a couple of labels so that they're distinct?

[tvdeyen]

No. The fly out is the missing part. So, keeping the current structure is fine.

[Mandily]

I'm closing this issue as we've decided nothing needs to be done here.