Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

DRAFT NOTES - Improvements to the out-the box Presentation Layer of uPortal

Note: Apologies for UK spellings (wink) Feel free to edit!

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.
  • Minimise difference in terms of output to the browser so that we really can share skins across institutions. For example using consistent way of handling channels, widgets, images, conventions and standards for naming. Most of the customisation takes place at the CSS level presently - if we had some standardisation in terms of usage and ids, we could potentially share more.
  • Need to genericise a standardised layout as far as possible though, and leave flexibility with the end using institution to customise to suit their own visual style.
  • Try move away from rework upon upgrades and towards some sharing

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.

Customisation 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.
Personalistion 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.

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

  • Jason taking the Rutgers theme, ripping out the logos and adding to possibly 2.5.1. and 2.6
  • Collier @ VT will contribute the VT theme - with icons ripped out etc
  • Duffy at Arizona - can add in some tree-controls type layouts.

Rutgers Layout

  • standards compliant version of SLM
  • css driven for layout.
  • improvements mostly 'cosmetic', less markup being moved around, quicker rendering, same preferences channel but prettier!

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.

  • No labels