Fluid Re-Orderer & uP3

[Gary Thompson]

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 either:

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 user. 

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.

Thoughts?

Gary


Colin Clark wrote:
> Eric,
>
> 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.
>
> * We need to minimize our JavaScript footprint by removing the rest 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: https://source.fluidproject.org/svn/fluid/components/branches/FLUID-49/ 
>   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.
>
> http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview
>
> 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,
>
> Colin
>
>
> 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.
>>
>> Thanks,
>> -Eric
>>     
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>