[uportal-dev] Fluid Re-Orderer & uP3

[Eric Dalquist]

Thank you for the research and writeup. That sounds like a great 
solution to me.

-Eric

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 
> 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
>>   
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3336 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080102/30bb67c0/attachment.bin>