Fluid Re-Orderer & uP3

[John Norman]

I'd like to suggest another use case, specifically because I tried to  
use Google Apps for Education Home Page in this way and the result  
was less than satisfactory. BTW the Google Apps for Education Home  
Page is essentially a co-branded iGoogle page for the institution.

What I wanted to do was create a home page for the institution which  
was part institution presented content and part user selected  
content. The user selected content would be portlets (often RSS  
gadgets) and all that was fine. For the institutional (locked)  
content I wanted it to look like ordinary html and hide the fact that  
it was a portlet at all. I could get part way by hiding the portlet  
frame, but at least one portlet (gadget) management icon remained -  
which spoiled the illusion. There were some white space/border area  
issues too.

The idea that the elements that are being dragged and dropped can be  
html fragments as well as portlets has overlap with Sakai  
requirements for page compostition. It would be really nice to have a  
good common solution...

John

On 2 Jan 2008, at 19:59, 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
>>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work