List View for Work Items in Planner [13]

[michaelkleinhenz]

Description

As a user, I want to view query results of Work Items in a list view that enables me to browse the resulting Work Items and it's childrens, open views on specific items and letting me update items in a meaningful way.

Acceptance Criteria

• [ ] The user can switch to a hierarchical list view of the current context. See the Context Views story for details on the context.
• [ ] The hierarchical list view displays the Work Items in the context in a list form using entries.
• [ ] Each entry has meaningful attribute views that identifies the Work Item represented by the entry. This is not changed from the current implementation.
• [ ] Entries that represent Work Items with a parent show also the immediate parent (only the direct parent) in the hierarchy, even when the parent does not match the current context. This parent is called the "extra parent" in the context of this story.
• [ ] Matching entries and their children (but not the "extra parents") are explorable (they can be expanded) and show all childrens regardless of applied criteria. The shown parents are not expandable and are only for informational purposes to provide a context.
• [ ] The user can open the quick preview view from an entry.
• [ ] The user can open the detail view from an entry.
• [ ] The user can delete a Work Item from an entry.
• [ ] The user can select an entry, setting the context for the quick add (see details on the context in connection to the quick add in the quick add story).
• [ ] Entries are sorted by order-of-execution by default, but only in the context of the expansion level. For example, all items on root level are sorted, then all childrens of an entry are sorted locally only.
• [ ] Drag-and-drop is possible to change the order-of-execution, but only in the context of the expansion level. For example, it is possible to re-order childs of a WI, but only within that child list. It is not possible to associate or de-associate a child using drag-and-drop for now.

Note: This story does not describe the final feature set of the list view. As the list view is one of the central views in the Planner, this will evolve over time. The current story is the feature set we can provide in the first step of that journey.

Note: There may be a parent grouping in a later story, but for now, we consider the extra parent as part of the entry component/view. Therefore, for this story, the parent is repeated with multiple childs being displayed.

Note: We may need a getParent() operation on the backend to be able to retrieve parent information of an "extra parent" entry when adding new childs of a highlighted "extra parent".

Note: The way the hierarchy is displayed only works when the Space is using a tree topology (there is a root of the tree with an unset parent value). The current backend implementation has to honor this when creating links.

Note: This story explicitly does not describe multi-selects and bulk operation. There will be a seperate story on this.

Note: This story does not touch the attributes displayed on an entry. This will be unchanged from the current implementation. There will be a seperate story on a more dynamic approach on this later.

Relationships

Put linked Team/Product story links here

Design Links

https://redhat.invisionapp.com/share/YZDOM6S2R#/screens

[michaelkleinhenz]

[sdash-redhat]

Refer Interaction Design notes slide 27, 29, 30 - https://redhat.invisionapp.com/share/6RCWHA1TX

Visual Design Notes: https://redhat.invisionapp.com/share/HTCX31SWC (VD work in progress)

Note: the text, data points were shown are for reference purpose to illustrate the interaction, based on actual data points there may be changes on how the screen might appear in real time post implementation.

[pranavgore09]

Modifications in API endpoint- GET Workitems API should include parent relationship for the only immediate parent if it exists. And included section must have that parent object details.

[sdash-redhat]

Question from UX: Should we distinguish visually the parent from the node?

[ldimaggi]

Can you add an explanation of the term "extra parent?" '...Matching entries and their children (but not the "extra parents") are explorable (they can be expanded) and show all childrens regardless of applied criteria. The shown parents are not expandable and are only for informational purposes to provide a context...'

[ldimaggi]

Do we want to reconsider this restriction: '... The shown parents are not expandable and are only for informational purposes to provide a context...'

Isn't it reasonable for a user to be able to traverse the ancestry of a workitem to its root?

[ldimaggi]

Just ton confirm - the user cannot delete a woritem's parent? '...The user can delete a Work Item from an entry...'

[ldimaggi]

Is this a typo? Are these statements intended to refer to the parent, or the extra parents? The user can open the quick preview from the extra parent. The user can open the detail view from the extra parent.

[ldimaggi]

When will we support sorting? Is this tracked in a different issue? Entries are sorted by order-of-execution by default, but only in the context of the expansion level. For example, all items on root level are sorted, then all childrens of an entry are sorted locally only.

[michaelkleinhenz]

Removed

• [ ] The user can open the quick preview from the extra parent.
• [ ] The user can open the detail view from the extra parent.

based on discussions with UX, will be re-added later.

[michaelkleinhenz]

@ldimaggi sorting is not yet in the context as this can get very complex. Also, exploring the parents would open up a pandoras box of all sorts of problems. I think it is better to keep the user focussed on what he actually has queried. I'd think a better way would be do do something like an hierarchy view of a WI as part of the detail view at some point that shows the whole tree of the particular WI.

[michaelkleinhenz]

Changed story text, made the extra parent term explicit @ldimaggi

[michaelkleinhenz]

Comment from @slemeur

Goals

This issue is listing few improvements and tweaks that we should do in order to cleanup the list of WI.

Quick Fixes

Positions, sizes and alignements

• [ ] Add more padding between the > arrow and the WI's status
• [ ] Fix the vertical alignement for the icons revealed on hover

• [ ] Fix the avatar placeholder to be the same size than a valid avatar

Others

• [ ] The icons used for "display in full screen" or "display quick preview" are difficult to understand.
• [ ] Add tooltip for WI status
• [ ] Add tooltip for WI type
• [ ] Add tooltip for "display full screen"
• [ ] Add tooltip for "display quick preview"

It is really hard to visually process the list of WI. As a quick fix, maybe we could:

• add a light line separator between each WI
• reduce the WI row's height

[kwk]

@michaelkleinhenz my suggestion would be to have circular gravatar CSS classes. That is in almost all of Sunil's designs right now. @xcoulon pointed out that we should also focus on the first impression rather getting features in. I think I speak for both of us that it's better to have a very polished UI rather than one or two more features.

[qodfathr]

@michaelkleinhenz I believe the spirit of what this issue was trying to accomplish has been met with the revised Planner (including capabilities on the backlog for the Planner). Does it make sense to close this particular GitHub issue?

[michaelkleinhenz]

Yes.