Metadata
- Source
- FLUID-187
- Type
- Sub-task
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Anastasia Cheetham
- Reporter
- Colin Clark
- Created
2008-01-28T11:28:51.000-0500 - Updated
2011-02-22T16:27:48.427-0500 - Versions
-
- 0.1
- Fixed Versions
-
- 0.3
- Component
-
- Reorderer
Description
This entails rethinking our definition of a drop target to allow empty columns to be drop targets, rather than only treating portlets as drop targets.
Comments
-
Barbara Glover commented
2008-02-11T09:55:05.000-0500 This bug was confirmed with user testing as a usability issue that is important. During our user test, there was a locked portlet at the top of the left column and no portlets below it. The user tried to drag a portlet from the right column into the left column. The user did not know they had to be hovering over the locked portlet (or any portlet) and just dragged straight across to the left column where it was empty. It is not intuitive to the user that they would have to first hover over a portlet in this case.
Also in the case a column was completely empty, the user may still want to move a portlet into the empty column. This is something they would intuitively think they could do.
- Barbara
-
Anastasia Cheetham commented
2008-03-25T16:16:59.000-0400 A fix has been implemented that considers columns as a special 'container' form of drop target, and adds the notion of "INSIDE" as a drop position. It works, but there is an inconsistent problem with the UI: Sometimes in the uPortal mockup file, if a portlet is dragged quickly over another portlet, the drop marker is incorrectly displayed at the end of the column instead of relative to the target portlet. In these cases, it seems the 'greedy' droppable option is not being heeded - both the column and the portlet are getting the 'over' event (the 'greedy' option is supposed to prevent that, and in most cases does). We will be investigating further, and if necessary filing bugs against jQuery.ui
-
Anastasia Cheetham commented
2008-03-25T16:27:56.000-0400 Also, currently you cannot use the keyboard to move portlets into an empty column.
-
Michelle D'Souza commented
2008-03-26T14:26:39.000-0400 Using the keyboard to move into an empty column is now working.
Navigating with the keyboard over an empty column is not implemented yet. -
Anastasia Cheetham commented
2008-03-26T15:46:01.000-0400 Navigating with the keyboard over an empty column is now implemented.
-
Anastasia Cheetham commented
2008-03-27T11:38:59.000-0400 Regarding the above-mentioned issue "if a portlet is dragged quickly over another portlet, the drop marker is incorrectly displayed at the end of the column instead of relative to the target portlet":
With the 'greedy' flag on (which it is), the column should get an 'out' event when the dragging cursor moves from the column space into the portlet space, and on this out, we unbind the mousemove handler, trackMouseMovement() (which is what displays the dropMarker) from the column (and bind it to the portlet on the portlet's 'over').
We are getting the out event, and hence we are calling unbind(), but the mousemove handler continues fire, and hence continues to incorrectly display the dropMarker. So it looks like the unbind() is not properly unbinding.
-
Michelle D'Souza commented
2011-02-22T16:27:48.425-0500 Closing issues that were resolved for 1.0 and earlier releases.