[SAK-18687] Ability to collapse site navigation Created: 22-Jun-2010  Updated: 14-Mar-2011  Resolved: 18-Sep-2010

Status: CLOSED
Project: Sakai
Component/s: Portal
Affects Version/s: None
Fix Version/s: 2.8.0

Type: Feature Request Priority: Major
Reporter: Steve Swinsburg Assignee: Charles Severance
Resolution: Fixed Votes: 1
Labels: None

Attachments: File Collapsed_navigation_SAK-18687_2-7-1.rar     PNG File HomeLinkMissing.png     PNG File blackboard-collapsed.png     JPEG File collapsed-menu.jpg     PNG File default.png     JPEG File expand-menu.jpg     PNG File left-icons.png     GIF File nav-collapse-menu-pane.gif     PNG File safari-oops.png     PNG File sakai-nav-max.png     PNG File sakai-nav-min.png     PNG File style regression.png    
Issue Links:
Depend
is depended on by SAK-19156 Add Capability for Tools to Request M... CLOSED
is depended on by SAK-23948 Request Maximum Tool Area from the Po... CLOSED
Relate
relates to SAK-19136 Add show/hide page navigation controller CLOSED
is related to SAK-19658 Tool collapse icon makes layout jump. CLOSED
is related to SAK-19187 hide navigation does not manipulate s... CLOSED
is related to SAK-19162 Visual indicator on tool icon when si... CLOSED
is related to SAK-19193 Change Default for Expand / Contract ... CLOSED
Property addition/change required:
Yes

 Description   

This came up on list, the ability to collapse the side menu. I remarked that it would be nice to be able to collapse the side navigation so only the icons are visible.

Heres one possible solution from Gonzalo:

--------
In your tool add the following:

<script type="text/javascript" src="/library/js/jquery.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$('#toggleToolMenu').toggle(function(e){
e.preventDefault();
$('#toolMenuWrap', window.parent.document).css(

{'width':'2px','overflow':'hidden'}

);
$('#content', window.parent.document).css(

{'margin-left':'1em'}

);
}, function(e) {
e.preventDefault();
$('#toolMenuWrap', window.parent.document).css(

{'width':'11em'}

);
$('#content', window.parent.document).css(

{'margin-left':'12.3em'}

);

});
});
</script>

<a id="toggleToolMenu" href="#">Toggle full width</a>

This should work in 2.6 - the above measurements assume the default Sakai skin - you will need to adjust for your case.
--------

However, for those that do adjust the skin, this requires some work to get right, for instance we have our icons on the left, not the right.
So I propose that a separate div be created at render time that contains only the icons from the toolmenu and when the 'collapse' function is required, it replaces the full navigation div with the smaller one. This should cater for all cases where people adjust the toolmenu.



 Comments   
Comment by Charles Severance [ 27-Aug-2010 ]

I am going to add a feature (optional) to the portal to always collapsing the menu possible. It will be controlled by a property. I am curious if anyone has a portal-level solution in production before I make it from scratch. I would really use a bit of design help on this - even though it is a pretty simple feature.

Comment by Vivie Sinou (Inactive) [ 27-Aug-2010 ]

I like how Outlook handles side bars (equivalent to Sakai's menu).

See attached screen shots. Instead of "To-Do Bar", you'd have "Menu" with the arrows.

Comment by Steve Swinsburg [ 27-Aug-2010 ]

I was thinking something like the way Blackboard does it, reducing the list to icons. For impl, I was thinking that a an alternate tool list is rendered when the main list is created, and just swapped out via jQuery.

Comment by Charles Severance [ 28-Aug-2010 ]

I just added basic functionality and infrastructure for collapsable navigation.

Still to do:

  • Better graphic design of the icons
  • Put the skin in control of the placement of minimize control
  • Possibly alter the actual tool markup to make it so you can
    minimize to icons instead of completely miminize - this might
    trigger a skin change or possibly add unnecessary cruft for
    accessiblity
  • Add a property to control this once the feature set is made clearer

This commit allows folks to play with this part of the UI to trigger more design analysis and commentary so we can get quickly to a nice and agreeable solution.

Comment by Charles Severance [ 28-Aug-2010 ]

svn commit
Sending portal-api/api/src/java/org/sakaiproject/portal/api/Portal.java
Adding (bin) portal-charon/charon/src/webapp/styles/images/arrow_down_right.png
Adding (bin) portal-charon/charon/src/webapp/styles/images/arrow_up_left.png
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/SkinnableCharonPortal.java
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/handlers/SiteHandler.java
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site.vm
Transmitting file data ......
Committed revision 81966.

Comment by Charles Severance [ 28-Aug-2010 ]

These are two screen shots of the UI for a normal screen with the little "minimize nav" button in the upper right. The second screen is after mimimization.

Comment by Steve Swinsburg [ 28-Aug-2010 ]

I think reducing to icons would be preferable as then a user could still navigate to other tools.

Also, the button to collapse could be on the toolbar near the reset, to save space, or down the side like in Bb. Screenshot attached.

Comment by Steve Swinsburg [ 28-Aug-2010 ]

Looks good on nightly but I'm not a fan of losing the top banner, only the tool menu, and then only to icons, not completely. We (and I suspect many others) need the top banner as per our branding guidelines. And keeping the tool menu as icons would make inter-tool navigation easier (as per previous comment).

Comment by Steve Swinsburg [ 29-Aug-2010 ]

I've noticed a 'flicker' when the nav is collapsed and then navigate to another site. The nav appears then disappears again.

Comment by Charles Severance [ 29-Aug-2010 ]

I will try to make it collapse to icons. Some schools don't use icons so I will likely have several options options: (1) don't collapse at all, (2) collapse to icons, (3) collapse icons too.

I think that we need to generate slightly different markup to allow to "collapse to icons only" because the decision of whether to put icons in or not is 100% up to the Skin. This is nice because no code needs patching to have a lot of control over icons - but the disadvantage is that the portal knows very little about icons. I am sure this can be done - the only question is which way is more elegant.

Angel collapses the top bar because Angel only shows icons on the left side. I figured do both in Sakai.

I will work on the flashing bit as you navigate pages - it is easy enough to fix once I know what we want. I will just default things to hidden - but then I lose the ability to dynamically compute the left edge of content... Hmmm. All this can be fixed as well.

Thanks for the comments.

Comment by Steve Swinsburg [ 29-Aug-2010 ]

Re the icons, I think if you output the same markup as what the current tool list has, minus the text, then skin implementors that choose not to have icons can still do so as they will have access to the same classes (icon-sakai-profile2 for instance). I think that should work.

Comment by Mathieu Plourde [ 30-Aug-2010 ]

At Delaware, we got rid of the icons in the menubar... I wonder how usable this could be if the menubar collapsed completely, without access to the icons at all? Any thoughts?

Comment by Charles Severance [ 30-Aug-2010 ]

Matthew - What we are thinking as we fine-tune it is that when a school has turned off the icons, the most usable approach would be to collapse from text with no icons to icons.

But, the trunk on nightly - hides them completely and it is reasonably usable - you simple pop it back open to get your buttons.

Comment by Charles Severance [ 02-Sep-2010 ]

Gonzalo just committed r82070 - r82072 with dramatic cleanup and improvement. I still need to add the property bit the the Java code. But should be fun to play with on nightly in a few hours.

Comment by Charles Severance [ 02-Sep-2010 ]

Screen shots showing Gonzalo's icons and placement. Much nicer than mine.

Comment by Charles Severance [ 02-Sep-2010 ]

We will need to add two properties tentatively named:

portal.allow.minimize.tools=true/false
portal.allow.minimize.navigation=true/false

You can separately enable/disable the minimization of the top logo and side nav. If neither are true, then the minimize is off and you won't even - effectively the same as 2.7. Both will default to true out of the box.

Comment by Thomas Amsler [ 02-Sep-2010 ]

The latest screen captures that Chuck posted look good

Comment by Steve Swinsburg [ 02-Sep-2010 ]

Looks great. The collapse to icons is excellent. There is some extra space below the icon in the minimised view which isn't present in the normal view (the normal view is probably a bit close to the House icon), but this is great work.

I think maybe portal.allow.minimize.navigation should default to false though so only the tool list minimises. Maybe a Sakai 2 TCC vote?

We should also run this past the Accessibility Working Group to get a sign off in that regard.

Comment by Alan Berg [ 02-Sep-2010 ]

0) The functionality is excellent.

1) On logging in and changing pages the arrow is seen briefly first loading in at the top of the page (Firefox 3.6.8). This flashing past of an arrow as you navigate around Sakai will be seen as an annoyance.
2) As you minimize you lose the Sakai Logo and a chunch of the HTML at the top of the screen. The movement is thus shuddery. Can something be done to smooth the transition.

Random idea, can there be a second GUI state that is turned on via sakai.properties where the logo is not displayed and the logout link is on the same line as the tabs with the sites name. This eliminate the shudder.

Comment by Daniel Merino Echeverría [ 06-Sep-2010 ]

I tried to apply these patches on a 2.7.1 but there were several failures, so I have applied manually the changes and I have generated two new patches for 2.7.1.

I attach a file "Collapsed Navigation SAK-18687 2-7-1.rar".

It seems to work, but please, test it carefully before merging, as I'm not an expert programmer.

EDITED: This 2.7.1 backport includes the revisions until 82085, I will add the rest when the status of the JIRA is closed.

Comment by Steve Swinsburg [ 06-Sep-2010 ]

This may have caused a style regression in the tool list (althoughth might be unrelated). The text of the selected tool seems very faint now, much more than previous, it's almost invisible. Also, it's got an underline now . See attached screenshot, 'style regression.png'

Comment by Gonzalo Silverio [ 07-Sep-2010 ]

Hi,

I had to rearrange the markup a bit for the toggle (but show icons when collapsed). r 82132 reinstates the former rendering, and adds space between the toggle icon and the rest.

Comment by Charles Severance [ 07-Sep-2010 ]

Dan - Thanks for the 2.7 back-port patch. If someone uses Dan's patch successfully - please add a comment here to let others know.

Comment by Charles Severance [ 07-Sep-2010 ]

Steve - the problem with the defaults as you describe is one of people even realizing such a feature exists. If I default both to true, folks who don't like top navigation minimization (like you) will quickly realize they don't like like it, and then quickly turn it off.

If on the other hand I default top minimization to off, few if any will ever realize that there is a subtle new feature buried beneath hundreds of properties and imagine that such a thing might exist and find what the property is and then turn it on and as such never even get notified if the feature exists. Also, if we default it off, it will never get properly tested.

In a sense, your logic that we poll folks as to how they will set the option is not the right indicator of what the default should be. We have lots of examples where we did not democratically pick a feature's default - but instead wanted the out-of-the-box/demo to showcase features which could be turned off. Often our defaults are intended to communicate something rather than attempting to mimic the probability distribution of the value in the ultimate running production systems.

In the other topic you mentioned if this introduces any Accessibility regression or we should improve the markup for the feature in some way - that would simply be a JIRA to file and fix.

Comment by Charles Severance [ 07-Sep-2010 ]

Added the properties and passed them into the Velocity.

Fixed Alan's issue (1) above by hiding the toggler until it was moved into place.

svn commit
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/SkinnableCharonPortal.java
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site.vm
Transmitting file data ..
Committed revision 82144.

Comment by Charles Severance [ 07-Sep-2010 ]

Gonzalo, In testing, I found a weird behavior on Safari, reproduced in the following steps: minimize, maximize, minimize again, and then you will see the maximize icon stay to the right and not move back to the left. You can click on it and it works. It is just positioned incorrectly.

I am guessing it might have been introduced when you added the "white space" nudge.

I attached an image of the confused look when the icon stops moving.

It worked fine in FireFox and IE 8 - although a border appears around the image in FF and IE8.

Comment by Charles Severance [ 07-Sep-2010 ]

It also hops pretty badly on IE8. I think that we will need to put the classes in the markup as it comes from the server rather than doing too much hide/show in the document ready bit. I think that I can fix this if you can fix the Safari losing track of where the icon goes.

Comment by Charles Severance [ 07-Sep-2010 ]

Fix the hopping/bouncing (Alan's comment #2 above). Markup comes from the server pre-minimized or pre-maximized so the document-ready code only does minor adjustments rather than changing layout.

Also made sure that we ignored the cookie when not logged in.

svn commit
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/handlers/SiteHandler.java
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/gallery-frame-top.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/gallery.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includePage.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includePageWithNav.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/page.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site-frame-top.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/worksite.vm
Transmitting file data .........
Committed revision 82145.

Gonzalo - the weird icon alignment in Safari is not fixed.

Comment by James Marca (Inactive) [ 08-Sep-2010 ]

Tried it for the first and only time just now.

My main comment is that the navigation hiding action is disconcerting. Although the arrow points left, the whole screen "repainted" and jumped up and left. I was left with a "what the heck just happened" feeling, and had to maximize to see what went away.

Two suggestions that might make this less disconcerting (and might just add a whole mess of potentially buggy code).

First suggestion: use a jquery UI type of animation to shrink the header and sidebar, so that the user can see what is going away as it goes away.

Second suggestion: make the arrow point diagonally (northwest rather than west).

Otherwise, nice addition.

Comment by Gonzalo Silverio [ 09-Sep-2010 ]

r82176 fixed Safari issue, r 82181 eliminated outline on toggler

Comment by Steve Swinsburg [ 09-Sep-2010 ]

I have found a bug when the following config is set:

portal.allow.minimize.tools=true
portal.allow.minimize.navigation=false

If I click to minimise the tool list, then switch site, the banner disappears. The only way to get it back is to maximise and force refresh the browser. I've cleared the browser cache.

Comment by Charles Severance [ 09-Sep-2010 ]

Thanks Steve - I will get on that - it may be related to my code to minimize hopping in IE8.

Comment by Charles Severance [ 09-Sep-2010 ]

Steve - Your settings combination should work in trunk. All known issues are now fixed totally awesomely.

Alan - hit me with your best shot. Fire Away.

svn commit
Sending portal-api/api/src/java/org/sakaiproject/portal/api/Portal.java
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/handlers/SiteHandler.java
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/gallery-frame-top.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/gallery.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includePage.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includePageWithNav.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/page.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site-frame-top.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/worksite.vm
Transmitting file data ..........
Committed revision 82198.

Comment by Steve Swinsburg [ 09-Sep-2010 ]

Verified the fix for my report above. Thanks!

Comment by Daniel Merino Echeverría [ 13-Sep-2010 ]

I attach a new file with the latest changes, tested in a fresh 2.7.1.

It seems to work fine, but it should be tested more deeply.

Comment by Charles Severance [ 13-Sep-2010 ]

Thanks Dan.

Comment by Brian Richwine [ 13-Sep-2010 ]

When I log into http://nightly2.sakaiproject.org:8083/portal with IE 8.0.7600 on Windows 7 or XP, the left side navigation is missing the text "Home" for the home icon, and in its place is the "Profile" text. The profile tool's icon appears to be missing. See HomeLinkMissing.png (attached to jira).

To reproduce,

Using IE 8, Login to http://nightly2.sakaiproject.org:8083/portal

I used an instructor account that I created.

Comment by Brian Richwine [ 13-Sep-2010 ]

A few quick accessibility notes:

1. The "Toggle Menu" icon accepts keyboard focus, and can be activated by the Enter key. But, it does not show visible focus. This will confuse keyboard only users (also, most adaptive technology emulates using the keyboard) as they won't be able to tell which element on the page they have tabbed to.

The missing visual indication of focus is the result of the following CSS ruleset in portal.css:
#toggleToolMenu, #toggleToolMenu:visited, #toggleToolMenu:active, #toggleToolMenu:focus {
outline:medium none;
}

The outline property is used to indicate visual focus. To maintain a visual indication of focus in both IE and other browsers, the default outline should not be disabled for the :active and :focus pseudo classes on elements that can be receive focus. Other icons and links on the page have "outline: thin dotted black" applied to them so they will show when they have focus. For example:

.portletTitle .title a:focus, .portletTitle .action a:focus {
outline:thin dotted black;
}

2. The toggle menu icon is being announced as: "Toggle Menus Toggle Menus" by adaptive technologies. This redundant announcement is due to the inclusion of both link text in the span tag of "Toggle Menus" and alt attribute "Toggle Menus" on the icon img tags. I recommend removing the span element and the text it contains all together.

Also, sighted folks get plenty of clues that the menus are either collapsed or expanded (including a change in the icon), but this is not apparent to blind/low-vision users. I recommend using alt attributes on the two icons that specifically indicate what will happen when the link is activated (either "Expand Menus" or "Collapse Menus").

A suggestion on implementing these changes follows:
<a id="toggleToolMenu" href="#" title="Toggle Menus">
<img id="toggleToolMax" src="/portal/styles/images/transMin.png" alt= "Collapse Menus"/>
<img id="toggleNormal" src="/portal/styles/images/transMin.png" alt="Expand Menus" style="display: none"/>
</a>

3. If a blind / low-vision user has accidentally (or otherwise) collapsed the menus, they might be frustrated by the lack of access to a logout link. I suggest including a visually hidden, but still accessible to adaptive technologies logout link when the menus are in the collapsed state. This could be accomplished by applying the skip style to the logout link.

Comment by Steve Swinsburg [ 14-Sep-2010 ]

SAK-19136 has just been created which adds a different type of collapse icon. Incorporating this would make the collapse function similar to the Blackboard collapse screenshot above.

Comment by Charles Severance [ 14-Sep-2010 ]

Brian - thanks for the comments. On your first - we will simplify the markup - we are just trying to do too many things I think. I also want to place the minimize icon properly before page load completes to reduce IE8 hopping after document ready.

In terms of the focus issue - my first reaction (please correct me if I am wrong) is that folks with screen readers would not want enter to minimize navigation at all - I would think they would not even want to see it - after all it is just shifting things around - it does not change the semantic meaning of the page in the least - so it seems a bit of a waste to use the enter key / focus to toggle minimize.

That said, I don't know what the enter key does on an unmodified portal.

Comment by Brian Richwine [ 14-Sep-2010 ]

Hello Charles,

The visual indication of focus issue applies to sighted users who can't/don't use a mouse. There are many types of disabled users (not just screen reader users) who use only a keyboard when using a computer, so interfaces need to be navigable and usable through the keyboard.

It is a good thing that the toggle menus link accepts focus and works via the enter key – this enables its use by any non-mouse user. But, sighted users need to know when the control has focus (via a visual indication) so they know they are on it and that they can then activate it if they choose to. The other issue with controls that don't show visible focus is that anyone navigating Sakai by keyboard (tabbing through the controls, etc.) will get confused as to where they are at while navigating the page which lowers to overall usability and navigability of the page for keyboard only users.

Visible focus is covered by WCAG Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are. Specifically WCAG Success Criteria 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) – http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible

My comments in #3 about the screen reader getting confused by the missing logout link are due to the fact that some screen reader users will accidentally activate the toggle menus link or will activate it wondering what it is there for. Also, there are several use cases where a screen reader user could want to use the toggle menus function to minimize the navigation. For instance:
1. The screen reader user is working with a sighted assistant, and the sighted assistant collapses the navigation.
2. The screen reader user has some vision and is also using a screen magnifier to zoom the page. Since the monitor size is fixed, screen magnifier users actually value their screen real estate more than a sighted user and would greatly benefit by the collapsed navigation (by zooming in 200% they can only see 25% of the screen at a time). Minimizing the navigation allows them to more easily focus on the tool's content while the screen is magnified.

The minimized navigation view does change the functionality of the page, in that the logout link is not available in the minimized view. Sighted users will know that they need to expand the menus to get to the logout link, but unsighted / low vision users will not. Many adaptive technologies provide the user with a tool that will provide the user a list of all the links on the page which they can easily navigate. If a screen reader user brings up a links list while the navigation is minimized, the logout link won't be there and they will get confused and frustrated. It is easy to use CSS to position the logout link off screen (not visible, but still available to adaptive technologies). This way the same visual effect can be had while maintaining the availability of the logout link. The "skip" class already exists in Sakai's CSS that does this and is used by many Sakai tools. I'd be happy to help with the coding changes to achieve this if you wish.

Comment by Charles Severance [ 14-Sep-2010 ]

Brian - Thanks - I knew there was a logic and I was just not seeing it. Gonzalo is reworking the markup a bit based on the IE8 stuff and perhaps he can fold this right in. I appreciate the offer for help and may take you up on it once we get through the current round of cleanup. It is probably easier for you to just patch it than to explain to me what I should do

Comment by Mary Stores (Inactive) [ 16-Sep-2010 ]

Actually, there's a good reason why a screen reader user using JAWS would choose to activate the Toggle Menu link. When the link is activated, thus collapsing the Tools Menu, JAWS reads the description for each tool, something which does not happen in the default (expanded) view. This would actually be a very useful feature for people using Sakai for the first time.

As of yesterday when Brian Richwine and I looke at this, we found two things:

Brian said that this collapsing navigation is only being developed for the Tools menu. If it were in the future, for example, going to be used for My workspace (it's the only one I can think of where you might have as many options to choose from as tools), it would be confusing to a adaptive technology users to hear, "Toggle menu. Toggle menu" and not know which menu is referenced. Even if the collapsing navigation will only be used for the Tools menu, it would still be helpful to hear that the Tools menu is collapsed or will be collapsed when that link is activated.

I could also not logout when the Tools menu was collapsed. I was very surprised to search for that link and not find it. I then remembered to activate that "toggle menu" link and then found it. Although this is only slightly inonvenient, I do think the site would be more useable and acessible for other assistive technology users if the link was there.

Comment by Charles Severance [ 18-Sep-2010 ]

Brian - I fixed the HomeLinkMissing problem - it turned out we had this problem all along in IE but no one noticed until you were testing this JIRA. That was not introduced by SAK-18687 - but it is now fixed. Thanks.

svn commit
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includePageNav.vm
Transmitting file data .
Committed revision 82360.

It was broken all along because of an extra double quote on in the markup for a selected tool that freaked out IE8. But all is now better.

Comment by Charles Severance [ 18-Sep-2010 ]

Mary - Thanks for the comments. I changed the text to "Expand/Collapse Navigation" I hope that is more descriptive - if you can come up with better text, let me know.

In terms of moving the logout back and forth, I would rather not for now. We are really not changing markup all that much for now and the hope is to keep the impact on existing skins to a minimum. I worry is we move logout into that tab bar, most sites float that left and there is no space for logout.

Comment by Charles Severance [ 18-Sep-2010 ]

Commit changes to the max/min functions to remove parameters and instead look into the portal object.

svn commit
Sending portal-charon/charon/src/webapp/scripts/portalscripts.js
Sending portal-impl/impl/src/bundle/sitenav.properties
Sending portal-impl/impl/src/java/org/sakaiproject/portal/charon/SkinnableCharonPortal.java
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/includeStandardHead.vm
Sending portal-render-engine-impl/pack/src/webapp/vm/defaultskin/site.vm
Transmitting file data .....
Committed revision 82361.

Comment by Charles Severance [ 18-Sep-2010 ]

This one is done and tested on nightly - thanks everyone for so much help with this one. If there is something wrong - feel free to file another JIRA.

Comment by Daniel Merino Echeverría [ 20-Sep-2010 ]

I'm trying to add the latest changes of 82361 to our 2.7.1, but there are changes on site.vm and includeStandardHead.vm that I don't know how to merge.

I'm afraid that this task overcomes me. If any other more skilled programmer wants to merge the patch in 2.7, we'll be glad to test it.

Comment by Alan Berg [ 20-Sep-2010 ]

From Oszkar Nagy (design lead Sakai 3).

At the request of QA

Thanks for showing me this, I think it's great and definitely useful. Here are my thoughts on it based on seeing Chuck's video and trying it out on the nightly server both with a desktop browser and my phone's browser (HTC Desire).

Generally I think it works reasonably well and I didn't notice any bugs during my short test.

Small screen device users, power users, frequent users will like you very much for this I think.

The cookie based remembering my setting is sweet and useful I think.

The functionality seems a little bit over-engineered though. IMVHO when different tools can "take over" and trigger a mode change unexpectedly (from collapsed to expanded or reverse - like the bascLTI) it can be confusing, especially since nothing set the expectations in the user that a layout change will happen (when I simply wanted to navigate). This is a simple tool where people are used to simple functionality, and I think consistency here is a bigger benefit than the intelligence behind the automatic collapse/expand triggered by a tool. I think if users set a setting it should stay like that across all tools/tabs until the user specifically changes it.

Visually the collapse/expand icon is very similar to the menu items, in fact it feels a little bit as it was part of the menu - but something is broken as there is no menu text next to it. I think its shape and size should be different from the menu icons, to emphasize the difference in intent and functionality. Also mentally the two are very different, one is a menu for navigation the other is a setting. This difference should come through visually as well.
In fact the current icon size would be good for the collapse/expand icon and the menu icons could be slightly bigger IMVHO (about 32x32) in collapsed mode, which would help hitting them with more accuracy on a small screen device even with fingers. On my test I had to zoom in on my device just to hit the icons in collapsed mode, then zoom out back as the font size was too big at that zoom level, and I could easily read smaller sized text. It would be good if the icon size would be big enough to be able to hit it at a zoom level where users are comfortable reading text too - taking out 3 unnecessary actions. Also in terms of frequency the navigation icons would be used more often than the collapse/expand icon.
Regarding shape/positioning I would try to avoid to put the collapse/expand icon in line with the menu icons in expanded view, and/or at least modify it a little bit to look a bit more different than the navigation ones, the white space underneath by itself is not enough I think.
I realise this is easier to say than to do - it needs some thinking as it is not trivial where and how to put it.

Not sure where the "Logout" link has gone if the header collapses too. I think when collapsed, it should move down to the right hand side of the tab bar (with a colour giving more contrast on the blue background).

The jump from one state to the other (ie collased or not) might be too sudden for some users to process and understand what happened especially if both header and navigation is collapsed. I think animating the menu collapse to the left and the header to the top would help understand better what happened. It could be quite fast and simple animation - similar to what happens on a Google search result page when you expand/collapse facets or search result types on the left hand side bar - just to be able to follow it with your eyes a little bit.

Could not see the tab highlight on the collapse/expand icon, first I thought you can't tab to it, but then I discovered that it's there but not visible.

Please take this only as 2p comment based on a small test, and quite limited knowledge in Sakai2. Might be also missing bigger picture things.

Generated at Wed Sep 18 22:19:45 CDT 2019 using Jira 8.0.3#800011-sha1:073e8b433c2c0e389c609c14a045ffa7abaca10d.