uPortal 3 UI - 2006-06-19

[Introduction to come soon, just trying to get the mockups posted]

Key Points

• Drag-and-drop customization
• Uses AJAX to reduce page reloads
• No "customization mode"
• XHTML 1.0 Transitional
• Primarily CSS-based layout (still using a table for columns unless someone can show me a bulletproof CSS-based column example)
• Highly accessible to screen readers and by people using keyboards vs. mice
• What else?

Icons, Colors, and Spacing
This is just a rough mockup I made quickly to get something out for people to comment on.  Colors were picked to get things out the door, not to look good.  Agonizing over these things so early on would be a waste of time.  These things will definately change in when it comes time to release something.

Inspiration - these sites served as my inspiration for how the interaction should work.

• Liferay
• live.com
• google.com/ig
• my.yahoo.com 

I've put questions I need answers to in green. 

Normal View

This is the normal view of the portal.

Page Header 

• Text Only - (rough idea) Presents the portal in a text-only-optimized mode.  The thinking here is that sometimes even a logical reading order in the HTML or on screen is still problematic for some.  This link would switch uPortal to a completely different theme that presents different navigation/customization options specifically designed for screen readers.  This introduces a long term maintenance problem since there are now two theme transforms to worry about, but hopefully the community will pick this idea up (if it generally considered worthwhile) and someone with a specific need for this will keep it up to date. What do you think of this idea?
• uPortal Settings - Take you to the uPortal Settings view.  See the 4/28/2005 designfor an overview of this screen.
• Help - We have help content, right?
• Log Out - ...
• Portal Logo - a graphic

Tabs

• Icons - A per-tab icon.  Do we want this?
• Tab Menu - Displays the tab menu.  Only works with JavaScript enabled.  A purely CSS based approach is not possible with IE6. Is this correct?  For the active tab, the menu arrow is always shown.  For inactive tabs, the menu arrow is only shown when mousing over the tab.
  • Move Left/Right - simple
  • Move to <Tab Name> - makes the 'tab' a 'page' of the tab specified (see pages
  • Rename - provides a way for the user to change the name of the tab.
  • Delete - deletes the tab
• Add Tab - Adds a tab named 'New Tab' to the end of the current list of tabs.  If a user cannot add a tab, this doesn't even appear.
• Dragging a Tab - When a tab begins to be dragged, it is removed from the tab list, made semi-transparent, and a dotted outline is shown over valid drop zones.
  • If the tab is released over an invalid drop zone, it snaps back to its original location.
  • If there are no valid drop zones (all of the other tabs are part of pushed fragments) then none of the tabs will be draggable.
  • When dragging a tab, tabs that have had their movement restricted by the layout manager will present some UI to the effect that they cannot be moved.  Perhaps a symbol on the mouse cursor.
  • What additional feedback is required?

Pages

I'm calling subtabs Pages so I don't have to call them subtabs.  Anyone have a better name?

• Icons - They're just like tabs.
• Page Menu - just like the tab menus
• Add Page - just like Add Tab
• First/Default "Page" - The first/default page is simply the parent tab.  It cannot be moved/reordered.  It is there to allow navigation between pages without having to click the actual tab to return to the default view.
• Dragging a Page - See Dragging a Tab above.

Add Content

Appears disabled if content cannot be added to the current page.  Takes you to the add content screen which still needs to be designed.   When a portlet is selected to be added, it is added to the to the last available position of the current page.  This means as the last portlets of the last column.  New portlets will be highlighted with a fading highlight effect when added.

Change Layout

• With JavaScript enabled, a menu appears allowing the user to change the number of columns on the current page.  Unavailable options will be greyed out (if one or more columns are not removable via fragment permissions).
• When moving from fewer to greater columns: new, empty columns are created of equal width
• When moving from greater to fewer columns: portlets from the columns being removed are added to the last column in the new layout.  There is no "even distribution" of portlets.
• You cannot remove a column with channels if you have nowhere to put them: If you have three columns (with portlets in each) in your layout and two are unremovable, you can go to four columns, but you cannot go to two columns.
• The last option in the menu is a link to the Change Layout interface, simliar to the uP 2.5 DLM preferences channel.
• If JavaScript is disabled, takes the user to a customization UI simliar to the uP 2.5 DLM preferences channel.

Portlets

• the >> is the collapse/expand button.  The button adopts the convention of indicating the current state of the portlet.  (see My Yahoo or live.com)
  • Up - portlet is collapsed
  • Down - portlet is expanded
• Icons - A per-channel icon.  Do we want this?

up3-portlet-menu.png* Customization Menu - same as other customization menus

• Portlet Actions - Help, Settings, Detach, Focus/Maximize (which one?), Delete  - Am I missing any?  Can I remove some?

• Dragging a Portlet - Similar to dragging tabs/pages

Site Map

This is sorta mirrored after flickr, but in our case shows your tab hierarchy. What do you think?

Accessibility Support

Accessibility is a major design goal, since uPortal is focused on university needs.  I'm currently working on enabling three rough scenarios:

1. Mouse/JavaScript Enabled
   • Dragging and dropping portlets/tabs/pages
   • Clicking on the arrows brings up menus
2. Keyboard/JavaScript Enabled
   • Portlets/tabs/pages can be moved using the Move Up/Down arrows on the menus
   • Tab focusing arrows brings up the menus
3. Keyboard/JavaScript Disabled
   • No menu arrows are visible
   • Portlets can be removed via Delete button on toolbar
   • Further customization options available in Change Layout interface

AJAX Support

The new uP3 will make heavy use of AJAX, especially behind-the-scenes calls to the portal for layout management operations.

For channels though, the portal will only use AJAX for switching between portlet modes: Normal, Edit, Help, and others.  Why?  We have no safe way to make portlets use uPortal 's AJAX functionality if they weren't written to use it explicitly.  We're not comfortable "rewriting" links and forms inside of unknown portlets to make their calls via AJAX.