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
[EMAIL PROTECTED]
http://fluidproject.org/mailman/listinfo/fluid-work
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
