Closed pgreenwo closed 9 years ago
Thanks! I'd missed the point that position within a priority row is significant. All the implications listed make sense, and will be fixed.
On point 4, the wrapping of items where the screen size is to small was deliberate, in order to accomdate smaller screen sizes. I've assumed that we want the app to work on tablets and mobile devices. Is that correct? It's a small css change to prevent wrapping, but we should chat about what a user with a smaller screen should see.
Points 1 and 2 are now resolved, however it has revealed another issue with the drag and drop:
Currently when you drag a card on top of another card they exchange places. I think that the card should be dropped on that place but the card it is dropped on, and any existing cards to the left of it, should move 1 place to the left PROVIDED THAT THE ROW ISN'T FULL.
If the row is full, the card in the target space shouldn't shrink (indicating the drop action isn't available) and if the card is released the selected card should revert to where it was dragged from.
Why? If you drag a new card to the top right position you are saying that this is your new top priority objective, and that it depends on everything else in that row being done before it can be achieved successfully. Constraining the number of cards in a row forces the user to think carefully about how they "chunk" the work activities and to think through the obstacles that must be surmounted before the highest priority objective can be achieved. But the drag and drop action says nothing new about where the card underneath should go. It is most likely to be a pre-requisite objective to the objective it has been replaced by.
Regarding item 4, I think that the wrapping breaks the logic of the presentation (ie. priority and sequence), so I would like it not to wrap. I don't think that a small screen (iPhone/phablet) is a reasonable device to use for this application. I think that something like an iPad mini device is about the smallest I'd want to worry about - and it looks fine on that through a browser. (I was anticipating having to use landscape for a decent view, but portrait seems better for the moment - we'll see what happens when we put content in the cards.)
As per: https://github.com/tableflip/posc/issues/13#issuecomment-67741176 the required behaviour when moving a card:
if row is full?
// Deny
else
// Move existing cards left until the slot is free, and allow the move.
We'll add visual cues when the move is denied, otherwise the user may assume an error occurred if there action is ignored.
Yes
Implemented and deployed to http://posc.meteor.com
The cards should right-align in the priority rows.
Background
As a communication device, the POSC tool is intended to answer the question: "What should I do next?" for members of a large self-organising team or entity (>100 people). The board is intended to show priority on the left axis (top priority at the top), and sequence on the bottom axis (using the western standard of left as next and right as last).
So that the top priority objective is at the top right, and its pre-requisite objectives are to its left. (The key insight is that a pre-requisite to the top right objective is also a top priority.)
Implications
This has a number of implications:
1) Any new card should be created in the right-most available space in it's priority line. 2) There should be no gaps between cards. 3) For the trash area, this logic is destroyed as there is no priority or sequence, so left alignment seems a smart choice in this area. The card behaviour in JQuery Gridly would work for the trash area. 4) When you reduce the width of the browser, the priority sequence breaks onto two lines. This shouldn't be allowed for the priority lines (don't care about the trash area, but naturally the width will be defined by the priority lines if we keep it below the POSC board.).
You can see this functionality on the prototype. The main issue with the interface behaviour of the prototype is that you can over-fill the priority lines.