UP3 Theme & Skin Concept 1

1) Quick Navigation Menu
This handy little menu can be used to navigate any portlets in a users layout. When a user selects a portlet, the system behavior would simply be to focus that portlet. This feature would give users persistent access to any portlet in the portal from one easy location. Depending on how this would be implemented, this feature could also help disabled users since screen readers would hit this menu 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 see 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 of all of these tools much like Mambo's back end UI. Ideally, all of these tools would 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 that provides access to the Preferences options. I'm not sure about the "Custom Settings" title, but the idea is to have a roll up of preference options.

5) Quick Link Icons
These icons represent quick link / tray functionality. The concept here is to allow users to have quick access into key portlets or portal functionality 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
Page headers are simply titles that re-enforce the tab a user is in. The idea of a page in this design is a slight departure from Collier's concept of a page in that these pages reflect a renaming of what we are currently calling tabs. The reason I'm calling them pages rather than tabs is because tabs are navigation metaphores and pages are conventionally what are understood to be destinations. This nomenclature adjustment could make things a little easier for the user to understand.

7) Page Menu
In addition to selecting a tab to navigate to a page, a user can also use this menu.

8) Variable Tab Navigation
This AJAX powered tab navigation system will allow users to add as many tabs as they want without concern for horizontal screen real estate. 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 offered.

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 makes sense to at least throw it in 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). It would also be nice to distinguish between narrow and wide columns – forcing portlets to be developed for one or the other. This would offer a cleaner (visually easier to understand) and more conventional UI.

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.