UP3 Theme & Skin Concept 1

1) Quick Navigation Menu
This handy little menu can be used to navigate all portlets in a users layout. By selecting a portlet, uPortal should focus that portlet view for the user. This feature would give users persistent access to any portlet in the portal from one easy location. Depending on how this would be implemented, it may help disabled users since the screen reader would hit this list first.

2) Updated Logo
This is an optional logo that could be used in place of the current logo. Click here for more information on this subject.

3) Admin. Tools Menu
Users with administrative privileges would get this menu. This menu would list all of the administrative tools/portlet (i.e. Groups Manager, Channel Manager, Etc.) in uPortal. Ultimately, I would like to see a portlet that consolidates a dashboard view into all of these tools much like Mambo's back end UI. And ideally, all of these tools should be completely re-designed to create a cohesive user experience across all of the workflows – but that's another discussion.

4) Custom Settings
Think of this as a menu for the current Preferences options. I'm not sure I'm completely sold on the title "Custom Settings" yet, but the idea is to have a roll up of preference options.

5) Quick Link Icons
These icons represent a quick link / tray functionality. The idea being that users would have quick access to key portlets or portal features with the added layer of alerts (i.e. mail notifications) where ever appropriate. The edit link next to the icons implies a UI that would allow users to select which set of quick link icons they want to display in this area.

6) Page Headers
As a slight departure from Collier's concept of a page in that these headers identify the tab a user is located on. The reason I'm calling them pages rather than tabs is because tabs are navigation metaphores and pages are conventionally what are understood as destinations (or screens). This is just a nomenclature adjustment that could make things a little easier for the user to understand.

7) Page Menu
This is a redundant navigation option for navigating the pages (or what are currently called tabs). Instead of clicking on a tab to get to the desired page, a user can also use the menu option.

8) Variable Tab Navigation
This AJAX powered tab navigation system will allow users to add as many tabs as they want without concern for the vertical screen space. When tabs exceed a given browser width, they get rolled-up into a fly-out menu selector. Also, users will be able to re-arrange tabs on the fly by dragging and dropping their location. Color coding tabs might also be a nice feature.

9) Section Menu
This menu implies a "tabs within tabs" option for those users who find a need to organize their portal with a secondary level of navigation. I think this whole idea needs to be flushed out a bit more, but I thought it would be nice to at least throw up here for discussion.

10) AJAX Columns
These columns display option selectors to hide the columns, delete them, and more. The columns also support drag and drop functionality so that users can easily swap the position of any given column. Users might also be able to grab an entire column and drag and drop it into a different tab (blue sky idea). This design suggest a properties specification for distinguishing between narrow and wide columns.

11) Example of a Narrow Column Portlet
This portlet should be displayed only in narrow columns and prevented from being displayed in wide columns.

12) Example of a Wide Column Portlet
This portlet should be displayed only in wide columns and prevented from being displayed in narrow columns.

13) Portlet Styles
Portlets should have UI options to change the labels / titles, colors, border styles, bg. transparencies, header icons, etc. on an individual and global level.

1) Custom Settings Menu
As mentioned in the description above, this is basically the "preferences" options rolled-up into an easily accessible menu. The current thinking is that certain options will invoke a lightbox UI that will grey out the screen and present users with preference functionality. Additionally, the user will be offered more "on-the-fly" options like swapping skins. By rolling over different skins in the list, the system will present a balloon type call-out with a thumbnail and possibly a description to aid the user in making a selection.

2) Portlet Menu
The portlet menu serves as a way to consolidate the various controls typically located in the portlet header. Doing a brief and fairly informal survey, I found that most users typically don't minimize / maximize their portlets very often. The do however focus them, but this interaction could be better handled directly with content that taps into the various portlet states (more on this at a later time). For now, the idea is that the portlet menu and the delete option will be the only controls that are surfaced up to the chrome level.

1) View Section
Sections are sub pages... or "tabs within tabs", depending on the nomenclature you use. The side bar offers a conventional way of navigating sections.

2) Clock Portlet
This is just a random sample of a portlet that could be developed for the side bar. Much of the thinking for the side bar has yet to be fully worked out, but the basic idea is inspired by docking tools found in operating systems. Ideally, the side bar can be hidden with an AJAX powered slide animation.

3) Tray Portlets
More examples of how the side bar can be used. Perhaps these are portlet states specifically designed for the side bar, or separate child portlets that have some form of integration with their respective parent portlet.

This mockup illustrates how a portlet could be dragged and dropped. A user would simply have to select the portlet header, invoking an cursor mode (directional arrows), and then drag to any "allowable" destination. If columns and portlets have narrow / wide specifications, the drag and drop behavior for portlets would have to obey those specifications.

This mockup illustrates a new direction for uPortal skinning. What I'm recommending here is that, in addition to the theme and skin concepts, the system also support a separate "branding" concept. The idea here is that an institution would be able to establish a branded skin whose key attributes would persist even after a user would select a different skin. This would serve the purpose of letting users personalize their portal experience without jeopardizing the brand requirements an institution might have for their portal. This example also implies a background image that could be changed by the user. Future concepting might address GUI options that allow users to build their own skin.