Navigation Feature Team (1.5)

Topics: Announcements, Core
Coordinator
Mar 15, 2012 at 12:41 AM

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.

Useful features: multiple menu management, local navigation menus, breadcrumb.

Limitation: only the simplest implementation should be included in the module, leaving fancy rendering as the responsibility of the theme author.

Coordinator
Mar 15, 2012 at 1:02 AM

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.

Mar 15, 2012 at 1:38 PM

+1 for a hierarchical tree

Mar 15, 2012 at 2:08 PM
meixger wrote:

+1 for a hierarchical tree

+1 too but I would like mine with a localization build in flavor ;)

Developer
Mar 15, 2012 at 4:28 PM

+1 for an hierarchical tree as Sebastien suggests, as well as having each item a "Path" property.

Mar 19, 2012 at 9:59 AM

+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.

Mar 20, 2012 at 1:50 PM

I just implemented caching on a hierarchical module I created for an Orchard website.

Many of the features could potential match the feature list, so I just uploaded it to the gallery: https://gallery.orchardproject.net/List/Modules/Orchard.Module.Contrib.NavigationExtension/0.1

Mar 20, 2012 at 10:46 PM

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.

Developer
Mar 22, 2012 at 11:35 PM

@thisisit Nice, thought about integrating your changes within the Advanced Menu mod?

@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.

Coordinator
Mar 23, 2012 at 12:31 AM

1.2.3 is exactly like 1/2/3

Developer
Mar 23, 2012 at 12:36 AM
Edited Mar 23, 2012 at 12:37 AM

Yes, it is. I thought you meant human-readable path that uses item 'slugs' (being arbitrary strings), sth like /first-item/second-item/some-other-item. Sorry if I misunderstood.

Mar 23, 2012 at 8:49 AM

@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 :-)

I'll gladly help with the navigation for 1.5.

Mar 23, 2012 at 2:54 PM

I've updated the module: https://gallery.orchardproject.net/List/Modules/Orchard.Module.Contrib.NavigationExtension

@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?

Mar 26, 2012 at 10:04 PM

+1 For the hierarchical tree

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!

 

Coordinator
Mar 27, 2012 at 6:48 AM

"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?

Mar 27, 2012 at 11:11 AM

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?

Mar 27, 2012 at 12:40 PM
geertdoornbos wrote:

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.

Mar 27, 2012 at 12:48 PM
thisisit wrote:

I've updated the module: https://gallery.orchardproject.net/List/Modules/Orchard.Module.Contrib.NavigationExtension

@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 :)

Mar 27, 2012 at 1:14 PM
AimOrchard wrote:
geertdoornbos wrote:

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.

Mar 27, 2012 at 1:20 PM

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.

Mar 27, 2012 at 1:55 PM

The admin template to replace navigation with drag-n-grop tree: http://www.downloads.binaryanalysis.net/?a=d&i=9jv6nrJ1IR

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.

@thisisit: what do you think?

Mar 27, 2012 at 4:32 PM

@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.

@ikutsin
- I don't think CulturePicker is 'done', is it?
- My 'Localization' fork has 'filter by culture'

Just some funny idea, is it possible to (re)use Projections to build navigation?

Coordinator
Mar 27, 2012 at 8:27 PM

@Piotr: can you take the lead here and report tomorrow on design decisions at our meeting?

Developer
Mar 27, 2012 at 9:15 PM

@Bertrand: Sure, np. 

Developer
Mar 27, 2012 at 9:23 PM

About the localization discussion and navigation.

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.

Mar 27, 2012 at 11:54 PM

That sounds like a good separation of concern. Well found!

Mar 28, 2012 at 7:13 AM
geertdoornbos wrote:

@ikutsin

- I don't think CulturePicker is 'done', is it?
- My 'Localization' fork has 'filter by culture'

Culture picker is implemented in CulturePicker and Multilanguage modules. Both use ICultureSelector to get and set value from cookie.

Mar 28, 2012 at 7:22 AM
pszmyd wrote:

About the localization discussion and navigation.

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?

Mar 28, 2012 at 8:14 AM

@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.

Mar 28, 2012 at 8:23 AM
geertdoornbos wrote:

@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.

Mar 28, 2012 at 8:41 AM

Another 15cent. What do you think about using the pushstate for navigation? This is something, which can not be included as a module.

Developer
Mar 28, 2012 at 1:34 PM

@ikutsin What do you exactly mean bu using the pushstate for navigation?

Mar 28, 2012 at 2:41 PM

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.

Developer
Mar 28, 2012 at 3:02 PM

Ah, yes, thanks for clarification. I'm not sure if it's in the scope of core, though. That could be easily implemented using an appropriate shape alternates, if needed.

Mar 28, 2012 at 3:04 PM
Edited Mar 28, 2012 at 3:06 PM
pszmyd wrote:

About the localization discussion and navigation.

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

Developer
Mar 28, 2012 at 3:18 PM

@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.

Mar 28, 2012 at 3:43 PM

@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.

Developer
Apr 5, 2012 at 4:04 PM
Edited Apr 5, 2012 at 4:06 PM

@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.

Developer
Apr 17, 2012 at 12:24 AM

@Bertrand Could you add me to the Trello board?:) My alias: piotrszmyd.

Coordinator
Apr 17, 2012 at 12:59 AM

Done.

Developer
Apr 17, 2012 at 1:17 AM

Thanks!

Apr 21, 2012 at 9:24 AM

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.

Coordinator
Apr 27, 2012 at 12:52 AM

Please start using this Trello board for task management on this feature team: https://trello.com/board/feature-navigation/4f9980ca14204e854c0117d0

Piotr, is there a fork or repository URL for the team already?

Developer
Apr 27, 2012 at 12:55 AM

Nope. But I'll set one up tomorrow.

Apr 27, 2012 at 10:24 PM

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.

May 1, 2012 at 6:45 AM

Love that you guys are using Trello.  

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?   

Coordinator
May 1, 2012 at 7:35 AM

@Brandon: it already is extensible today through INavigationProvider. Did you have something different in mind?

May 1, 2012 at 8:13 AM

@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!

Coordinator
May 9, 2012 at 3:02 AM

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.

Thanks,

Bertrand