I'm a little troubled by the lack of support or unifying voice for a continued evolving "core" navigation system for DNN.  Navigation is probably the most important/difficult concept in constucting websites and the dnnMenu should be a top priority focus for the entire DNN platform.  It bothers me when core team members and community members spend more time using 3rd party menu systems and then offering technical support for those menus via the forums.  I built my site with the new dnnMenu because Jon Henning recommended that the community should migrate to this menu since it was part of the core framework and roadmap.  Where is Jon's support form other core team and community members?  Why would core team members spend their time learning the intricacies of these other menus and not spend their time helping Jon continue the development of the supposedly supported core dnnMenu?  If the dnnMenu doesn't offer all the features found in other systems, it might be because no one is giving feedback/suggestions to Jon.  What is the philosophy of core team members going forward as it relates to navigation within the DNN framework? 

Thanks,

Paul

It's interesting you have that opinion Paul - and I sometimes I point out things to people who are looking for things that simply aren't built into the framwork - and this is very much the case for newcomers to dnn who have these menus they want to drop into their sites without a full understanding of the implications and involvement that the navigation provider itself actually does.  I have always advocated that in spite of the shortcomings the menu may have - it's actually quite a complex and flexible piece of code - so flexible that it's been a challenge to learn - to really expand it.

http://webcontrols.dotnetnuke.com/  this is Jon Henning's project - I can't fathom the hours these guys spend on tweaking, making compatible, extending and enchancing and I think I lost a whole year learning how the menu works - There are about 80 elements of code just for the menu that are a mix of inline and css references, and that's not including if you use html or ascx to develop your skins, the xml references are also diverse as is the images that can be used to make the whole look and feel - It took me literally months to get http://december.skincovered.com/menus.aspx right - and now I'm working on some 'dnn nav' menu items. 

There's also the other aspect of the menu functionality - the ability to allow third party providers into the mix broadens the audience.  I was quoting a job for a company not long ago - they do steel work - and I asked what sets them apart - they ran through a few things they do and I found out they have the largest range of colours you can paint your roof, including orange and purple.. .. I said that's a great thing to tell people.. and they said - No we don't want really do this - because they are a pain to do ....  My answer to them was - so what - who is going to have an orange roof?   But just picture a street of grey rooftops... and there in the middle was this bright orange one - - it stands out - but the fact is - the amount of people who want an orange roof is so small it's not going to change much .

What I'm trying to say is that I'm an advocate of keeping as much in the DNN space as possible and support it to the cows come home but people want to have choices and things that the menu doesn't do as well - unless you're very experienced in tweaking it.

I converse with Jon on the menu - he's always provided lengthy information, documentation, vision and links to his work - takes on board as many questions as anyone else and objectively makes changes.

I use different menus based on requirements for clients - eg.. if I have to provide a css only menu - I will use the http://www.snapsis.com menu - because it works and satisfies the client's requirements - and I like how it dynamically renders the sub pages in a css based format.. which is Search Engine friendly and fits how other sites are put together.

Sorry if I gave you the impression that I'm not a supporter - My goal is to have the whole menu infrastructure online on skincovered, with samples and code snippets.. but it's a huge job, and we're chipping away at it.

I have also provided a free dnn menu skin - not much but that was in early days - eg. mid last year but I've not had the time or resources to expand on it - until I worked out a way it could be presented in a manner I thought was going to be useful - and you know - this is an open source project, and to get all the people to ' walk the talk' is a big job - as we all have to live, generate some form of income and for me - I have so much research to do sometimes my head feels like it's going to explode.

So although things may not move as fast as we would like it's just hard to move any faster sometimes.

I hope this clarifies things - Jon's forum is the API forum - and there is API support and the webcontrols site.

Does this give you some more faith in the fact that the menu is here to stay for quite some time.

Nina Meiers

Hi Paul,

Yes, the provider model is what makes it extensible.  I think we are saying the same thing. 
Maybe you are expecting that all 3rd party menus that plug-in should be supported by DotNetNuke Corp. and/or the Core Team.  If that is what you are getting at then I don't understand why you would have that expectation.

The DotNetNuke core is extensible so that many different options can be made available, and so that those options can be supported by their respective developers.  Is there going to be overlap? Sure, but that is a good thing in my opinion.

If you are thinking that the few volunteers on the core team should develop and support every request or option that may be made available in a navigation menu then you should be aware that doing that will stiffle the growth of DotNetNuke.  There are many creative minds out there that are incented to develop for the DotNetNuke platform in many different ways, if we try to make them all fit into the "Core Box" then that will really cause a bottleneck in what is made available to the end consumer.