As part of the concepting offered by B. Collier Jones, and based on feedback and research from the field, I thought I'd pull together a few concepts for a UP3 skin & theme overhaul.
...
Main Screen | Description |
|---|
| 1) Quick Navigation Menu
This AJAX enabled selector handy little menu can be used to navigate all any portlets in a users layout. By selecting When a user selects a portlet, uPortal should the system behavior would simply be to 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 this feature could also help disabled users since the screen reader readers would hit this list 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 get 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 into of all of these tools much like Mambo's back end UI. And ideallyIdeally, all of these tools should 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 for that provides access to the current Preferences options. I'm not sure I'm completely sold on the title about the "Custom Settings" yettitle, 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 concept here is to allow users to have quick access to into key portlets or portal features 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.
| Warning |
|---|
| These icons are FPO (for placement only) and were grabbed from other, possibly commercial / licensed products, rather randomly while mocking up these designs. These icons are not to be used or reproduced without permission. At a later date, these icons, and consequently, these screenshots will be updated with OS friendly versions.
If you plan to use these screens in any of your own materials, please include this disclaimer. |
6) Page Headers
As 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 headers identify the tab a user is located onpages 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 as destinations (or screens)to be destinations. This is just a nominclature 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 In addition to selecting a tab to navigate to a page, a user can also use the this 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 horizontal screen spacereal 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 a nice featureoffered.
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 makes sense to at least throw up 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). This desgn suggest a properties specification for distinguishing 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.
|
Menus | Description |
|---|
 Image Added
| 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. |
Side Bar | Description |
|---|
 Image Added
| 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. |
Drag and Drop | Description |
|---|
 Image Added
| 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. |
Branding | Description |
|---|
 Image Added
| 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. |