Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Skins, Themes, ...Skins, Themes, ...DNN Navigation SystemDNN Navigation System
Previous
 
Next
New Post
8/24/2006 1:23 PM
 

It seems to me, that a large portion of the issues from this forum revolve around the DNN primary navigation. I can understand why the navigation model is good from a coders perspective, but from a designers perspective its far too restrictive. The site navigation is abstracted and limited by the rules required to make it work for many purposes. To be honest, neither designers or users care that much if the provider is perfectly architected when it doesnt let them do what they want. In my opinion the problem is that DNN is trying to use the same navigation provider/system for both primary site navigation and the ulitity navigation (settings drop downs etc). These are two completely differnet animals, site navigation is often the most creative and pivitol aspect of designing a site and its heart renching to restrict designers into a box, compared to utility navigation where people are much more willing to settle for the standard. There seems to be a need for a new module, that exposes the core HTML, CSS and JS and threads the data through whatever UI paradigm designers want, perhaps by templates. With only the security logic and menu/link tokens being locked away within the module. Im interested in some of the core teams thoughts on this.

 
New Post
8/24/2006 3:13 PM
 

First of all I agree with you that the navigation controls (read SolPart) are indeed the most complex part of skinning.

After building +20 skins from scratch over the last year, from experience, I can tell you that there is a lot you can do with solpart, but also a number of things I can't do with it. The styling of the menu is very, very elaborate, so from that perspective I think it is a good menu.
Where I have difficulty with solpart is in the following area's:

  • split menu's, multiple levels: I have used an adapted version of solpart with has a more flexible "level" attribute
  • multiple colors: e.g. use telerik
  • panel bar like behavior: I have used telerik panel bar
  • pure image menu's: I have used SchwingImageMenu

The new navigation control (DNNMenu) eleviates some of the above difficulties, moreover,  from a "standards" viewpoint, it is suppose to be much better.
So my point is: there are many alternatives you could consider, out of the box.

WRT to your better paradigm, I not exactly sure what you want, if you just want a valid page tree for a particular visitor, I think (mind you I am not a programmer) this is already part of the DNN source (through the Menu Data Provider).

Peter


Peter Schotman
Cestus Websites voor DotNetNuke oplossingen in Nederland
Contact us for your custom design and skinning work.
 
New Post
8/24/2006 5:39 PM
 
jeffrey_vella wrote

It seems to me, that a large portion of the issues from this forum revolve around the DNN primary navigation. I can understand why the navigation model is good from a coders perspective, but from a designers perspective its far too restrictive. The site navigation is abstracted and limited by the rules required to make it work for many purposes. To be honest, neither designers or users care that much if the provider is perfectly architected when it doesnt let them do what they want. In my opinion the problem is that DNN is trying to use the same navigation provider/system for both primary site navigation and the ulitity navigation (settings drop downs etc). These are two completely differnet animals, site navigation is often the most creative and pivitol aspect of designing a site and its heart renching to restrict designers into a box, compared to utility navigation where people are much more willing to settle for the standard. There seems to be a need for a new module, that exposes the core HTML, CSS and JS and threads the data through whatever UI paradigm designers want, perhaps by templates. With only the security logic and menu/link tokens being locked away within the module. Im interested in some of the core teams thoughts on this.

I also am not sure what you are shooting for.  With version 3.2, DNN for the first time exposed the raw data in xml format that represented the navigation hierarchy (see page 3 in this document).  This xml can be used in any manner people see fit.  If we just stopped here, designers most likely would be out of luck, for transforming the XML using XSLT or other DOM manipulation is typically not something in a designer's arsenal.  Typically sites use some form of webcontrol to display navigation structure (i.e. Tree, Menu, DropDown, etc.) and assigning properties to a control is fairly straightforward.  This is where the provider model comes in.   It marries the XML to the actual control.  If there is another control you would like to use instead, all that is necessary to work with it is have someone create a provider with it.

You state that you would like a module that exposes the core HTML, CSS, and JS.  This statement confuses me, since the HTML that would be given to you is not static.  Like I mentioned earlier we do offer the XML, which can be transformed to HTML however you like (assuming you know XSLT).  Templates is an interesting idea, however, I am not sure how you would define an action in a template, like fly out to the right instead of below...  Are you just referring to templating an individual menu item?  This is kind of possible today through the lefthtml, righthtml property paradigm.

You also state that the main navigation is completely different than utility navigation.  I assume by this you are referring to the main nav and the module actions.  From my programmer's perspective I definitely see them as the same.  XML node hierarchy -> glue (provider) -> WebControl + Properties -> HTML.

I have offered a free menu module from my site that allows a little more flexibility in designing the menu, however, it still comes down to data + WebControls + Properties = HTML.


 
New Post
8/25/2006 1:16 AM
 

Firstly, thanks for the response i appreciate it.

I also am not sure what you are shooting for.  With version 3.2, DNN for the first time exposed the raw data in xml format that represented the navigation hierarchy (see page 3 in this document).  This xml can be used in any manner people see fit.  If we just stopped here, designers most likely would be out of luck, for transforming the XML using XSLT or other DOM manipulation is typically not something in a designer's arsenal. Typically sites use some form of web control to display navigation structure (i.e. Tree, Menu, Dropdown, etc.) and assigning properties to a control is fairly straight forward.  This is where the provider model comes in.   It marries the XML to the actual control.  If there is another control you would like to use instead, all that is necessary to work with it is have someone create a provider with it.

I guess it all depends on where you draw the line between developer and designer, if your workflow is that the designer delivers some comps and your developers 'make it work' then you're most likely going to have to interate back and forth to get it right or compromise on your design's functionality to save time. The other option is to move the line so that your designer moves into the developers realm as much as possible (the trend in user experience); building out the design and deciding how the thing is constructed in terms of using tables or divs controls etc and such then typically the representation will be more accurate and made faster. Problem with the later is that there’s a big learning curve with DNN. The documentation, as you say, talks about XML, XSLT and can be very hard to follow for many designers. If you want something done you have to find a control that can be customized to fit your vision, then get a developer to make a provider and probably alter the control.

You state that you would like a module that exposes the core HTML, CSS, and JS.  This statement confuses me, since the HTML that would be given to you is not static.  Like I mentioned earlier we do offer the XML, which can be transformed to HTML however you like (assuming you know XSLT). 

Most good designers can create anything they can imagine (in terms of navigation systems) between HTML,CSS,JS and Flash. Its a very familiar area because designers have a perfectionist drive to marry up their concepts perfectly with the end product, whereas developers in my experience are more concerned with with the behind the scenes aspects of functionality. My point with all this, i feel the way its designed doesn't leverage this abundance of knowledge, instead of empowering designers by giving them the environment theyre used to they're hitting a wall. Maybe its just a learning curve with XSLT, personally im not familar with it but from what ive read so far it seems powerful, maybe all that we really need is some more documentation, tutorials and examples.

You also state that the main navigation is completely different than utility navigation.  I assume by this you are referring to the main nav and the module actions.  From my programmer's perspective I definitely see them as the same.  XML node hierarchy -> glue (provider) -> WebControl + Properties -> HTML.

What i mean is that a designer will spend a huge amout of time making sure a websites navigation is sexy as hell, a great deal of the overall design time is spent on the menu's intricate details because its the most highly used aspect of the site. People scroll over content; its about visual priority and menu is something that users have to focus on and interact with rather than glance over. I wouldn’t give a module dropdown menu on an admin-only interface the same sort of attention. So even though they work from the same mechanism, the concern might be 95:5 and my observation was that it doesn’t make sense to define the rule set by the minority.

Templates is an interesting idea, however, I am not sure how you would define an action in a template, like fly out to the right instead of below...  Are you just referring to templating an individual menu item?  This is kind of possible today through the lefthtml, righthtml property paradigm.

I have actually coded my own menu module, i basically hooked into the tab objects for the portal and added the admin/host nodes, hooked into the security aswell and looped through it all creating what i need. I've only exposed a few properties at this point because i was thinking about how templating could work. And i wanted to talk about it the idea, it shouldn’t be this hard and if there’s a way that my experience as a designer new with the product can help people and maybe the project reduce that learning curve then its probably worthwhile.

What i was thinking for templates was very much like putting your portal/container skin idea. You've got wrapper HTML and sub-templates for each tab item, so for example if you're building a horizontal menu your item template might be <div class=[x]><a class=[x] href=[x]>[text]</a></div> or it might be a table or span or a mixture of these. As much as possible is kept out in the open and can freely be changed. The security is invisible still, users only get shown what they should have access to see.

For examples sake, if i wanted to have all the tabs spewed into their own tables then use javascript to hide and show those layers based on mouse click. All that i need from the control is the URL/Text parsed for each item, the rest of the functionality can be controlled externally. With the wrapper template, the item templates, css and javascript. Using eventx script to marry css with javascript events onclick of the link with x class hide these tables and show this one.

 
New Post
9/1/2006 4:44 AM
 
Jon
you write:
I also am not sure what you are shooting for.  With version 3.2, DNN for the first time exposed the raw data in xml format that represented the navigation hierarchy (see page 3 in this document). 

But the link doesn't work...
What's this document...?
Thanks
 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Skins, Themes, ...Skins, Themes, ...DNN Navigation SystemDNN Navigation System


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out