Improvements to the out-the box Presentation Layer of uPortal

At the moment most of the UI work and testing is done at the institutional level and doesn't make it back into the community. Also there are problems with porting mods and changes across versions of uPortal.

Objectives:

• Default presentation layer using css and standards compliance.
• Maximize common markup for browsers so that we really can share skins across institutions.
  • consistent way of handling channels, widgets, images, conventions and standards for naming.
  • Increase customization possible through CSS
• Reduce work while upgrading between uPortal versions
• Ease customization for institution specific look and feel

Suggestions:

• Channels could have some intelligence about the amount of screen-space that they need in terms of column widths, rather than leaving this to the user to deal with.

• Would like to see a requirements document for the UI for uPortal's Layout Manager. Put on the wiki and get feedback and debate on proposed requirements.

• Need to 'unit-ise' UI customisations so that they can be easily deployed at other institutions easily. Would be great if you get stuff from the Clearinghouse with a clear set of instructions on downloading and installing it. Need a fairly standardised mechanism for sharing our stuff.

• Abstracting the customisation api that controls how folders are created so that the api can be customised at a local level e.g. to customise what happens when a user adds a tab

• Adding a tab - need to add a tab, then a column, then a channel - if we could slim this down that would be a huge improvement in and of itself.

Discussion

• Not happy with the current customisation options - need improvements to ease of use, accessibility and end-user discovery.
• Consensus that we are turning it off or end-users are not using it - quite a lot of users don't use because it's not that important to them

Quite a lot of institutions have turned off the ability to customise in their portals.

Seems to be consensus that we don't want the clunky preferences channel - are there resources available for a large effort on a 'best of breed' layout manager? Quite a few alternatives to the current mechanism - drag and drop a la Google, or simple left, right up and down a la Yahoo.

Majority of end-user customisation at the skin level, or removing channels. Should the majority of effort not go into making it easier to push content at users, rather than end-user customisation? since use of the portal is often a secondary goal for many people.

AL - quite a few people using Aggregated Layouts - a couple using simple layouts. Lot of interest in terms of Distributed Layouts - supposed to be a simpler migratation path to DLM than ALM from simple layouts. Also DLM is a bit more flexible.
Problems pushing layout fragments via AL damaging layouts if the user is logged in. Memorial running push fragments when the portal is down.

ALM / DLM - DLM has more flexibility in terms of being able to edit tabs with pushed content on it. DLM not quite production ready yet.

A lot of the customisation tools are too generic and too powerful, but end up being not powerful enough.
Serious changes to the rendering architecture not feasible at the moment - may be improved in uP3.0

ALM vs DLM - no major changes in the 2.6 time frame, but possibly later.

• Abstracted APIs for customisation and layouts - a discussion worth having.*

Personalisation of layout vs customisation of layout

• Personalisation handled pretty well with ALM and DLM, but customisation is not very good at all.
• Personalisation is pretty hard via fragments.xml and we wouldn't like to see this in a user preferences style thing either. Not good from either a user or administrator side of things.
• UC Berkeley would like to be able to push fragments to different groups and allow users to remove/edit some channels, but not others. They would also like to be able to create editable pulled fragments, which users can select to receive only if they are interested in the subject matter. Finally, they would like to be able to ensure that if a pushed fragment changes, users receive any channels added or updated, but retain any other changes they've made to the fragment. It might be nice to have a setting that allows portal managers to decide whether they want to merge user changes into an updated fragment or not. And of course it will be necessary to have a UI that allows users to manage their fragments in a coherent manner.

Actions:

• Need Documentation of conventions, standards and requirements
• Tutorial style guidance to illustrate common usage, styles, design intentions
• Need a Standing Committee / Interest Group / Discussion Group to continue discussion and keep focus around UI. If anyone can devote any time to this- let Jason Shao know

Immediate short terms goals for 2.6

• Unlicensed user taking the Rutgers theme, ripping out the logos and adding to possibly 2.5.1. and 2.6
  • standards compliant version of SLM
  • css driven for layout.
  • improvements mostly 'cosmetic', less markup being moved around, quicker rendering, prettier!
• Unlicensed user @ VT will contribute the VT theme - with icons ripped out etc
• Unlicensed user modeless integratedModes
• Unlicensed user at Arizona - can add in some tree-controls type layouts.

General rule: If anyone has something to contribute and it compiles, then it can go in the sandbox for comment (Sandbox - an area of CVS that stuff that's not quite finished and ready to go into the main code tree).

Join the JA-SIG Developers list and make sure that any work we do takes place in the JA-SIG web-space. Use the wiki for discussions.