[uportal-dev] Fluid Re-Orderer & uP3
eric.dalquist at doit.wisc.edu
Wed Jan 2 19:03:21 UTC 2008
Thank you for the research and writeup. That sounds like a great
solution to me.
Gary Thompson wrote:
> Fluid and uPortal Reodererists,
> Happy New Year! I hope that your holiday was joyous.
> I did some research into use cases for locked portlets. It seems that
> institutions that do lock portlets do so sparingly with the goal of
> 1. Keeping prioritized content at the top (usually news/announcements
> content), or
> 2. Preventing a user from accidentally removing content
> For #2, this is really more of a problem with the add portlet UI,
> which has substantial usability problems and is painful. Some
> institutions lock portlets not because they don't want users to be
> able to remove the content, but that they get too many tech support
> calls from users who accidentally removed content they wanted, and
> then were not able to successfully use the add portlet UI to get it back.
> So, my conclusion for the DnD reordering of portlets is to go with our
> initial gut instinct:
> * locked portlets always go to the top of column
> * if there is more than one locked portlet, they are ordered by
> priority (a system parameter set and changed by an administrator)
> * reorderable portlets may not go above locked portlets within a
> column (or between locked portlets if there are more than one)
> With that, I believe that everything remains the same for the DnD
> design except for the identification of locked portlets as such to the
> Currently, I am thinking that we identify locked portlets to the user
> on drag attempt with a simple message, something like "This portlet is
> locked and cannot be moved."
> For reordering of unlocked portlets, it should indicate drop targets
> above (or between) locked portlets as invalid, and follow normal
> invalid drop target behavior.
> Colin Clark wrote:
>> Good question. Here's a quick overview of where we're at from the
>> client side:
>> * Fluid 0.1 had a bug in it that prevented nested Reorderers from
>> working happily together. Michelle D'Souza managed to commit a fix
>> for this before the holidays, so this problem should now be resolved.
>> of Dojo from the Reorderer. We've had much better luck with jQuery,
>> and it's generally a bit smaller. Should make for lighter download
>> times for the portal. This work is about half-finished.
>> * Anastasia has an in-progress branch with part of the functionality
>> required for this Fluid portlet layout manager. It's available here:
>> Anastasia's core change was to write a new layout handler that
>> uses the layout JSON object sent down from the portal.
>> * We've got to make a couple of API changes to the layout handler to
>> make this code a cleaner and simpler.
>> * Gary Thompson and Shaw-Han Liem are working on making this really
>> easy to use. We've got a new design pattern that outlines some of
>> the considerations, and they're working on new wireframes to ensure
>> the interaction is simple and discoverable.
>> We've been a bit behind schedule on this work, but it is now our top
>> priority for the new year.
>> Have a great holiday,
>> On 21-Dec-07, at 1:11 PM, Eric Dalquist wrote:
>>> Anastasia, Jen,
>>> Just wondering what the status of looking into using the Fluid
>>> reorderer for uPortal 3 is.
>> Colin Clark
>> Technical Lead, Fluid Project
>> Adaptive Technology Resource Centre, University of Toronto
>> fluid-work mailing list
>> fluid-work at fluidproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3336 bytes
Desc: S/MIME Cryptographic Signature
More information about the fluid-work