Navigation Menu - Current class

Coordinator
Oct 3, 2012 at 3:59 PM

(Originally posted as an issue by JohnMcAvinue)

It would helpful if the navigation option in the menu could have a "current" class when that is the page currently being viewed.

This would facilitate alternative CSS styling which would give the user situational awareness so they that know where they are from looking at the navigation menu.

This can be implemented using Javascript but it should only require a minor change to the framework and will add an extra element to the styling capability.

Coordinator
Oct 3, 2012 at 4:04 PM

Have you implemented this in JavaScript?  If so, can you share it with us?

Otherwise, I am not really clear on what you mean by current class?  How can the (stateless)  server know what is being currently viewed? I may be missing the point, but perhaps you can spell it out a little more.

Oct 4, 2012 at 7:21 AM

I like this.
Also, how complicated would it be to add a back button, or leverage the browser's back button, to navigate back to the previously displayed entity. Our users keep asking for that.

Oct 4, 2012 at 7:26 AM

>Otherwise, I am not really clear on what you mean by current class?  How can the (stateless)  server know what is being currently viewed?

Maybe I am also misunderstanding, but I think the idea is that at the time the UI generator / renderer renders a view for a specific entity, it should inject "current" into the class attribute of the current history item so that it can be styled differently.

I don't see how this would be a problem for the stateless server. The server obviously knows which entity is currently being rendered, else it wouldn't be able to render it. :) Or am I wrong?

Editor
Oct 4, 2012 at 8:09 AM

On 4 October 2012 07:26, jfbosch <notifications@codeplex.com> wrote:

...I think the idea is that at the time the UI generator / renderer renders a view for a specific entity, it should inject "current" into the class attribute of the current history item so that it can be styled differently.



Hi Richard,
John McAvinue mentioned this to me yesterday when I was at the office; I suggested he raise an issue on it rather than just a discussion so that's my bad.

The suggestion is though as jbosch surmises. John was saying he could hack this with Javascript, and would that be ok? ; I said it'd be better just to get the requirement folded back into the framework since it sounds simple enough to implement and others would benefit.

Dan
Coordinator
Oct 4, 2012 at 9:02 AM

Ah, I now understand that you are talking about the History.  Sorry -  I didn't get that before.

I agree that it would be not be difficult for the framework to append the Current attribute  -  but I'm not clear on what the advantage is.  The current object is always the one at the right hand end, isn't it?  Is it not possible to select the last one in a list using CSS alone?  (I'm no CSS expert, I should say, so I might be wrong)

Coordinator
Oct 4, 2012 at 9:05 AM

No problem, Dan.  I just prefer to keep things in Discussion until:

1. At least one of the developers isclear as to what the issue/requirement is ;-)

2. We agree that what is being asked is possible, and consistent with the broad objectives of the framework

Oct 4, 2012 at 9:16 AM

"I agree that it would be not be difficult for the framework to append the Current attribute  -  but I'm not clear on what the advantage is.  The current object is always the one at the right hand end, isn't it?  Is it not possible to select the last one in a list using CSS alone?  (I'm no CSS expert, I should say, so I might be wrong)"

Another approach would be to not have the current entity in the history at all as it is not history yet. Then the last entity in the list would be the previous one.

But I still think this would be a good addition:

"Also, how complicated would it be to add a back button, or leverage the browser's back button, to navigate back to the previously displayed entity. Our users keep asking for that."

Oct 4, 2012 at 11:34 AM

Hi,

Thanks for opening this discussion so promptly.

This suggestion is solely to allow the currently selected page/section to be displayed differently in the navigation menu using CSS. It is not related to history, but will allow some form of situational awareness to be reflected in the navigation menu.

I was able to add a "current" class to the navigation menu items using Javascript which looks up the values in nof-object and nof-actionname. It matches these against the navigation options in the menu and then with a bit of CSS, they are displayed in a different colour. It's primitive but it works and adds a greater degree of styling and hopefully better usability.

Here's the Javascript:

$(document).ajaxComplete(function () {
    //Get the Object and Action names from the page that is being viewed
    var objectName = $(".nof-object a").text();
    var actionName = $(".nof-actionname").text();
    SetCurrentNavigation(objectName, actionName);
});

function SetCurrentNavigation(objectName, actionName) {

    //Remove existing current classes
    $('.nof-menuname').each(function (index) {
        $(this).removeClass('current');
    });
    $('.nof-menuitems button').each(function (index) {
        $(this).removeClass('current');
    });

    //Find the relevant navigation hyperlinks and add the "current" class
    $('.nof-menuname').filter(function() {
        return $(this).text()== objectName;
    }).addClass('current');

    $('.nof-menuitems button').filter(function () {
        return $(this).text() == actionName;
    }).addClass('current');
}

Coordinator
Oct 4, 2012 at 1:24 PM

John

I will try out your Javascript (I can't right now) to see what it does.  But can you post a screenshot to show the net UI effect that you are achieving?  Thanks

Coordinator
Oct 4, 2012 at 1:27 PM

Also, how complicated would it be to add a back button, or leverage the browser's back button, to navigate back to the previously displayed entity. Our users keep asking for that."

The back button does allow you to navigate backwards. Currently collections are not supported but we have an outstanding ticket for that. 


Oct 4, 2012 at 1:46 PM
richardpawson wrote:

John

I will try out your Javascript (I can't right now) to see what it does.  But can you post a screenshot to show the net UI effect that you are achieving?  Thanks

Hi Richard,

See image below. Payments is displayed in a different colour in the Navigation bar because that is the section the user is in. Find Items Awaiting Payment is displayed differently because that is the page currently being viewed.

As I said, it is primitive!

Coordinator
Oct 4, 2012 at 9:39 PM

Thanks for the screenshot, John.  I finally understand what it is you were suggesting.

I'm glad you got it working in JavaScript and I suggest you just stick with that.

The suggested change to the framework, however, is not something I can support.  It would actually be a lot of effort and would have derogatory side-effects.  Assuming that you are running Naked Objects in Ajax mode (the default now) then the menu bar is not updated at all as you navigate between objects. 

And, to be honest, I think that the potential usability gain is minimal, if any.   Thanks for sharing the JavaScript though  -  if others like this idea they can use it.

Oct 5, 2012 at 10:22 AM

Hi Richard,

Thanks for looking into this for me. No problem at all if there are any side effects or if it's a bit of work, the JS is there now and it was easy to implement.

All the best,

John

Oct 8, 2012 at 6:47 PM

Hi Richard,

The request was to create an atribute in the generated markup that identifies a node of the DOM tree as unique.

As you say, this can be done with a snippet of javascript however I like my UI to work without Javascript (at least in testing mode).

There is an absolutely immense UI benefit to adding a class="current" attribute/value pair to a DOM node. With this node in the tree, the CSS parser can use parent, child and sibling relationships to build a near infinite variation of user interface designs.

In particular, the unique node allows the hiding and showing of children with the display:none; style definition.

This is your framework, so if you're opposed to uniqueness in the DOM for an academic or philosophical reason then that's fine.

But I can tell you, as a Head of User Experience in a large agency, I have clients who are in all kinds of pain because of this issue.

All the best,

Dug

 

Coordinator
Oct 8, 2012 at 7:00 PM

Dug

"if you're opposed to uniqueness in the DOM for an academic or philosophical reason"

What I said was that this change would be a lot of effort ... not that I was opposed to it for academic/philosophical reasons.

"have clients who are in all kinds of pain because of this issue."

Do you mean clients using Naked Objects?  If so, please contact me offline (rpawson at nakedobject dot net)  -  I'm always keen to hear about large commercial implementations using Naked Objects.  We provide commercial services to those that need it:  and perhaps if the pain is large enough they'd be willing to fund the kinds of changes they would like.

Best

Richard