Navigation Feature Team (1.5)

This is the thread for the navigation feature team, where one can volunteer to do work and discuss design.

Strawman design proposal:

We want to have a hierarchical menu out of the box in Orchard. Piotr's menu has been very successful, and may be a good basis for this. We would like a streamlined user experience for it though, and significant performance improvements so that Orchard 1.5
can be at least as fast as 1.4 is, out of the box, and even with a hierarchical menu.

Throwing an idea. This is something I have seen in CmsMadeSimple, and I found it very simple and practical.

The idea is to have only one "main" menu, like this is the case right now, which would be hierarchical. The menu is displayed using a widget, and its configuration will tell what "portion" of the menu has to be displayed, either it is the top level item,
and how many sub-levels to render.

Thus the management is still one page, where we can browse the whole hierarchy of links. Creating a separate menu is actually creating a separate top level node, and rendering a widget based on it.

On top of that, like in Advanced Menu, there could be different types of menu items.

All menu items are still content items, and they have a "Path" property to handle the hierarchy (instead of relationships). This is done like this in Taxonomy to help with performance when trying to load a portion of a hierarchy. Or having the full menu
in cache otherwise.

+1 for localization support: when a user visits a multi-language site, the hierarchical menu should display items in the selected language, and the items paths should point to the localized content for the selected language. I the user selects a different
language, menu items should refresh accordingly. The site admin would set the default language for the site, and if a content doesn't exist for the selected language, the default language content should be displayed.

It is pitty that AdvancedMenu doesn't support Localization. Therefore I'm more on simple heirarchial tree of MenuItems.

I did implement conversion from list of MenuItems into MenuItems hierarcy as a frontend template and module (did find the idea on some blog, can't find it). It also has a widget for submenus. In addition I have an Admin template (which has to be enabled,
not selected) with JQuery drag-n-drop menu to orderup the items. Alltrhrough it is not very user friendly for sites with many pages, I believe it can be fixed with async nodes load. I can't just put 3 packages into the gallery which actually do one thing but
together.

I'did have chance to take alook into NavigationExtension, I like the idea about caching. Hopefully it will still support my MultiLanguage module.

@ikutsin It does, like Orchard as a whole (through enties in *.po files). It could also be done by binding menu items with specific culture and adding some filtering in the UI - I just didn't have enough time to add that yet. Good admin UI for that would
be also necessary.

@sebastienros Seb, isn't the Position (dot-notated) good enough to keep the hierarchy info? In addition, it keeps the item ordering on every level. I'm just thinking about the possible issues that can come up when paths change, items are being moved
from one subtree to another, items with similar slugs and so on. Path is good for human-readability, but I think we'd better stick to numbers when it comes to building hierarchy.

We should definitely rethink the menu-building logic. I totally agree we should get rid of the relationships and stick to flat list with some hierarchical identifier before rendering (so when the whole fetching, filtering etc. takes place). The performance
impact of having to traverse the tree of menu items (retrieved from Navigation Manager) to choose a subtree or mark an item as 'current' is huge - there need to be at least one recursive call at some point.

I'm willing to commit on helping building the navigation in 1.5, of course.

@pszmyd You are most welcome to use whatever you like :-) I'll expect to push some changes later today, with new caching (per widget), localization filter and a new sort filter. Note that changes in the alias doesn't affect the caching atm.

For 1.5 it would be smart to store the path along with the menupart, since it's a big effort to look up URL's for every MenuItem (in the breadcrumb for example).

I don't see any reason to change the menu positions/relations right now.

I'm implementing caching per Navigation widget in my module (to avoid caching the whole menu), and expect to cache a dictionary with the path/url as key for the breadcrumb widget, and the position as value.

For an UI improvement it could be a good start to look at the UI for Widgets/Layers, that's what I expect to do. But avoid doing anything fancy :-)

But keep in mind that content types with a menu part can also have a localization part (multi-lingual websites).
Culture selection in the admin navigation area would be nice (instead of mixing it all), but filtering inside the navigation provider is a 'must have'. I think most people don't want to mix content of different cultures.

'Menu translation' (*.po) is in every current navigation module (correct me if I'm wrong). I've only seen 'content localization' inside the CulturePicker module. That's (one reason) why the CulturePicker and AdvancedMenu are conflicting modules,
can't be used together (at this moment).

I proposed a patch whitin fork 'Localization' to have content localization inside the framework, so that navigation providers and widgets can use that to determine whether or not to show a menu item / widget. With that, the current implementation
of 'Main Menu' is content localized. Only menu items of the currently active language are visible. Other non-localized content (including menu's) will be visible.

Within this fork, I also added the ability to filter content based on the current culture using Projections.

For the new Navigation feature, I think it is important to determine what gives the best performance
a) query for menu-items that matches the current language, or
b) query for all menu-items and then filter based on the current language (this is the case in my fork)
(with caching aspect in mind)

Also important is the Position of a menu item. Content that is localized, will have multiple versions of it, one for each language. So each localized piece of content has it's own localized menu item. The position in the menu hierarchy is most probably
the same! So don't depend on uniqueness of the position when the position is indicated with numbers.

I'd love to see the new navigation feature as well as a culture selector inside Orchard. Multi-linguals sites 'out-of-the-box'! Just enable it :-) and go!

"I'd love to see the new navigation feature as well as a culture selector inside Orchard. Multi-linguals sites 'out-of-the-box'! Just enable it :-) and go!": like so many things, one person's "must have out of the box" is another's "I'll never
use that". Few sites are multi-lingual. How hard is it to install a module from the gallery?

Your're so right, everything can be a gallery module. With the right recipe it can have an 'out of the box' experience :)
I think a 'Few sites are multi-lingual' because it's more difficult to create them. There are lots of companies/people that want their site to be content localized (if they could). Navigation should take 'content localization' into account. Or not?

Your're so right, everything can be a gallery module. With the right recipe it can have an 'out of the box' experience :)
I think a 'Few sites are multi-lingual' because it's more difficult to create them. There are lots of companies/people that want their site to be content localized (if they could). Navigation should take 'content localization' into account. Or not?

I agree, most people don't bother with multi lingual because of the difficulty.

Having support 'out of the box' will make it easier for people to start making multi-lingual sites.

We'll sure have need for it, since our current (non-orchard) website that I'm porting is translated in 4 languages, and 12 more are planned.

@ikutsin: I've added a simple additional culture filter module, that extends the standard navigation widget. I don't know if there is a smarter way?

Well culture filter is nearly the same as it was used in CulturePicker and MultiLanguage modules. Good thing is that it doesn't filter menus without the culture. I did started with sub menus a while ago, now, there is no sence to finish it, I'll just
use yours, thank you :)

Your're so right, everything can be a gallery module. With the right recipe it can have an 'out of the box' experience :)
I think a 'Few sites are multi-lingual' because it's more difficult to create them. There are lots of companies/people that want their site to be content localized (if they could). Navigation should take 'content localization' into account. Or not?

I agree, most people don't bother with multi lingual because of the difficulty.

Having support 'out of the box' will make it easier for people to start making multi-lingual sites.

We'll sure have need for it, since our current (non-orchard) website that I'm porting is translated in 4 languages, and 12 more are planned.

I have to agree with Bertrand, everything can't be out of the box. Instead we could focus on making awesome docs for Navigation in 1.5, where we could specify which module does what and what module you need to do something.

So, what is the plan here? I really expect some decision on that part, because everybody has their own partial solutions which are not supported by each other.

Future of Navigation:

Will it become hierarchial out of box or converted to hierarchy and then cached?

Will MenuPart change?

Will be there anything out of box from: Breadcrumbs, SubMenu (widget to show menu in another place, not sure how to call it.. "2nd level"), Named menu (to have not only main menu, like AdvancedMenu has) maybe?

Future of multilanguage:
Making the Orchard to support multilanguage was relatively easy in 1.3, now in 1.4 there are more and more places where it has to be applied:

Culture picker - done

Navigation - filter by culture, more or less solved, but still needs clarifications.

AutoRoute - have culture name as a part of the path. Didn't see the implementation.

Distinguished search - I saw some module implements that, which is cool.

Projector - didn't test that, does it support filter by culture?

Additional filters in Admin UI - this needs a dirty hack with enabling the template, but not selecting it.

Rules - have one "culture="

I believe, that Orchard has to be at least multilanguage ready (for instance, as it is done with multitenancy), this feature is vital at least for Europe.I see no sense to spent >150MB memory on server just to host a "home page" with the same functionality
as any PHP CMS provide.

As the navigation admin is overridden in NavigationExtension, we can give it a try inside the module, as a separate tab for example, to let user choose. Generally it use own "to hierarchy" converter. But it can easily use one from module.

@JLedel I certainly do agree that not everything can be out of the box (that is: 'without gallery modules').

I think the new navigation should be designed to take content localization into account, not implement. If the design has extension points for one or more aspects, other modules can influence the navigation behaviour.

IMO the best approach would be to have totally separate menus for different languages and display them in
separate widgets. The layer rules engine could then be applied to display one or another depending on the current culture.

IMO the best approach would be to have totally separate menus for different languages and display them in
separate widgets. The layer rules engine could then be applied to display one or another depending on the current culture.

Sounds nice, it also mean out of box filter by culture in Admin Menu.

Do you mean to have several menu trees, and one of them can become "main" depending on culture?

I'm thinking about breadcrumbs and sub menus. Would they "understand" it too?

@ikutsin Oh alright, didn't know there were two CulturePickers! Didn't know about your module 'Multi Language', thought you we're speaking of multi language in general :-) I will take a look at it, let me know if you like to have feedback.

@ikutsin Oh alright, didn't know there were two CulturePickers! Didn't know about your module 'Multi Language', thought you we're speaking of multi language in general :-) I will take a look at it, let me know if you like to have feedback.

Sorry, my English is not very good. But, Yes feedback is always good, thank you :) It seems, we should move to another thread about Multilanguage discussion.

pushstate is HTML5 feature which makes async loading of the pages and store the correct links in the browser history. Generally page output depends on IsAjaxRequest header in request - to decide if it should show whole layout of the page or only a part of
it. This generally used to make client side not to load whole page during the navigation, making possible - for exmple play a music without starting it over when moving on a new page.

This technique is broadly used by media sites and social network sites.

IMO the best approach would be to have totally separate menus for different languages and display them in
separate widgets. The layer rules engine could then be applied to display one or another depending on the current culture.

@pszmyd, I've been thinking about this approach. if I understand correctly, using the admin dashboard,
manually creating a separate menu for each culture? If that's the case, then IMO, while it might be a straight forward solution to implement for a small web site with few links, and 2 or even 3 cultures, it will become cumbersome, once the
site grows bigger. the maintenance side of these separate menus will become a headache for the admin, having to go through all the seperate menus one by one, every time a link is updated, deleted. Perhaps this solution can be implemented for 1.5 temporarily
just to get the multi lingual menu feature out of the way, but down the road I believe a more elegant solution can be found.

Perhaps adding Localization to the Advanced Menu Item in your advanced menus, where - for instance - the admin can add as many translations inside the Menu Item, could be in the form of a grid: "Culture - Menu Title Translation - URL".

Or another solutions, perhaps adding localization to the Alias
Module, where translations can be managed along the Aliases in the Manage Aliases Admin View.

Advanced Menu Item

@phusion On the other hand - managing a huge menu in a single GUI is a pain, believe me. Second thing - menu structure or menu item URLs may be different for different cultures, then what? You assume that the localization is only about translating the whole
thing, but that's not true in every situation. In lots of cases the localized sites differ on the structure level too. That's why I'd rather stick to separating the whole menus, not just making menu items localizable.

Making a good GUI for managing that is a different thing - it doesn't necessarily have to be like it's now. Eg. certain menu items could be linked together to allow quick switching between localized instances of a given item in different menus.

@pszmyd, I see your point, taking into consideration the possibility of
differences in menu structure for different cultures, is smart, and I haven't thought of that.

I agree that the management side is a separate task, that can be addressed with a good GUI that can ease the maintenance of these separate menus, especially with adding the feature of linking localized instances of the same menu item.

In this case, the solution you proposed (separate menus, widgets, layer rules for each culture) can even be used right now with orchard 1.4. And the heavy work will be coming up with a user friendly GUI to manage these menus.

@phusion Exactly - the idea is pretty simple and straightforward so it's possible to have it with 1.4 - it would involve using a separate module (eg. Advanced Menu) to have multiple menus available and a bit of coding (a custom
IRuleProvider) to allow creating culture-specific layers.

IMO, the simpler solution, utilizing as many existing Orchard features as possible, the better and less error-prone.

I really think drag n drop page ordering within a tree in the dashboard is the go and the basic menus (main, sibling menu, child menu and breadcrumbs) should fall out of that automatically. SilverStripe has something incredibly easy in this regard (paraphrasing
the syntax, excuse my lack of Razor knowledge):

//the items at the top level of the tree:

@foreach Menu(1)

<a href="@item.Link" class="@item.Mode"..>@item.Title

//the siblings of the current page:

@foreach Menu(2)

<a href="@item.Link" class="@item.Mode"..>@item.Title

//the children of the current page

@foreach Children

<a href="@item.Link" class="@item.Mode"..>@item.Title

//breadcrumbs

@foreach Breadcrumb

<a href="@item.Link">@item.Title</a> >>

It's that simple takes a minute to add to your templates so you can focus on the real content of the site.

@item.Mode tells you if the menu item matches the current page, the current section (parent), etc. so highlighting is a breeze. Anything beyond that for URLs is a matter of setting up simple routing rules.

Hi. I'm sitting here implementing a site in another .net CMS. Every time I get really frustrated with it, I'm reading up a little more on Orchard.

A subject that I find important is that the same content can exist under several branches of the tree. This is commonplace in the E-commerce implementation I am doing now, usually when presenting accessories to a product group, or related products.

In my specific case the menu structure would ideally be in the form of "hierarchical tags" decorating content. The content EGG would could have the tags PANCAKES/INGREDIENTS & WAFFLES/INGREDIENTS & ALLPRODUCTS generating

ALL PRODUCTS
-EGG
PANCAKES
-INGREDIENTS
--EGG etc...

Localization of the hierarchical tags would be able to not only translate the text but also customize the localized menu item, as only localized items would show up. This could ofc lead to some problems for the case of content that should only be visible
in the navigation of the localized version.

For the navigation stuff... This may already have been thought of, but I would like to see an extensible menu item provider. This would allow a module developer to write a provider implementation that could feed menu items into the navigation
in more complex scenarios. Ex: Security Checks, Store Hours, or really anytime where logic is custom and results in a dynamic menu. Make sense?

@bertrand Hmm... I should have realized that was there. As long as the new stuff plays nice with that, I think it covers most scenarios. Taking a look at the Advanced Menu module it looks like it's based on that too. Thanks for the response!

Feature Team Leaders, please join us tomorrow at 1PM Pacific Time for a status report at https://join.microsoft.com/meet/sebros/TWFQ3LYH (Lync client required). If you can't join us, please leave us a note here giving status before the meeting.