Display and Update Area Field on Work Item Detail View [4]

[michaelkleinhenz]

Description

As a user, I want to change the Area of a Work Item on the detail view.

Functional Acceptance Criteria

1. The detail view contains a dropdown that displays the current Area of the Work Item.
2. The user can change the Area value of a Work Item by using a typeahead dropdown that contains all Areas of the current Space.
3. It is not possible to set an empty value for the Area.

Non-functional Acceptance Criteria

1. All changes are done in-place.

Note: Despite popular belief, the Planner is not contextualized by the Area (for now). The Planner displays all Work Items across all Areas of the current Space.

Note: Every Work Item has a default Area set, there are not Work Items without an Area value. That default Area value is also contained in the typeahead dropdown.

Note: The Area is one-fold for now, but will be a hierarchy later. The implementation should reflect that.

Related Tasks

• UX: UX for associating a work item with an area in detail view FOLLOW UP: Display and Update Area Field on Work Item Detail View fabric8-ux#204
• CORE: API to fetch all the areas for a space Add link to get areas in the response of space api fabric8-services/fabric8-wit#781
• CORE: API to associate a work item and area Associate a workitem with an area fabric8-services/fabric8-wit#787
• PLANNER: Write a service to fetch all the areas for the current space Write a service to fetch all the areas for the current space #1012
• PLANNER: Write a service to associate a work item with the selected area Write a service to associate a work item with the selected area #1013
• PLANNER: UI for displaying Areas as dropdowns on the work item detail view UI for displaying Areas as dropdowns on the work item detail view #1014
• PLANNER: Write functional tests for Display update area field on WI detail view

Related

1. Userstory Display and Update Area Field on Work Item Detail View [4] #913.
2. Userstory Filter Work Item List by Area [3] #914.
3. UX Wireframe: Selecting an Area in the WI

[AdamJ]

• UX Wireframe for Areas
• Fabric8-UX Story

[ldimaggi]

Just to confirm:

• Does every space include at least one area? (A "default" area?)
• Does every workitem require that it be associated with an area?
• Can a work item be associated with more than one area at a time?

Thanks!

[AdamJ]

@ldimaggi

• Every space has at least one area - Spaces create default Areas upon creation of the Space
• Every Work Item must be associated with an Area
• Work Items cannot be associated with more than one Area at a time

[ldimaggi]

Thanks Adam!

…

On Tue, Feb 7, 2017 at 11:28 AM, Adam Jolicoeur ***@***.***> wrote: @ldimaggi <https://github.com/ldimaggi> - Every space has at least one area - Spaces create default Areas upon creation of the Space - Every Work Item must be associated with an Area - Work Items cannot be associated with more than one Area at a time — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#913 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnOPeyYsDM0K5P3txVRv6Q3i8zvDuurks5raJuzgaJpZM4L5m0s> .

-- Len DiMaggio (ldimaggi@redhat.com) JBoss by Red Hat 314 Littleton Road Westford, MA 01886 USA tel: 978.392.3179 cell: 781.472.9912 http://www.redhat.com http://community.jboss.org/people/ldimaggio

[maxandersen]

is the default area anything but the "/" area ?

[maxandersen]

"It is not possible to set an empty value for the Area." this seems wrong to me.

Do you expect every user reporting issues being able to know what area is the right one ?

That said, if "/" (the root/default area) is considered a non-empty value then that sounds fine.

[Mgranfie]

Adam jump in here... I believe we settled on surfacing the "/" as "/default is the space name as the highest level of the area."

…

On Wed, Feb 8, 2017 at 7:06 AM, Max Rydahl Andersen < ***@***.***> wrote: "It is not possible to set an empty value for the Area." this seems wrong to me. Do you expect every user reporting issues being able to know what area is the right one ? That said, if "/" (the root/default area) is considered a non-empty value then that sounds fine. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#913 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARTwq_ouG5RKAUCMPK4iPaCPQKZcxQ4Pks5raa_MgaJpZM4L5m0s> .

[ldimaggi]

Follow-up questions: Is the path composed of space + areas + what else? Is there a clear definition of the elements that are contained in the path as opposed to the URL? Thx! On Wed, Feb 8, 2017 at 10:08 AM, MonicaGran <notifications@github.com> wrote:

…

Adam jump in here... I believe we settled on surfacing the "/" as "/default is the space name as the highest level of the area." On Wed, Feb 8, 2017 at 7:06 AM, Max Rydahl Andersen < ***@***.***> wrote: > "It is not possible to set an empty value for the Area." this seems wrong > to me. > > Do you expect every user reporting issues being able to know what area is > the right one ? > > That said, if "/" (the root/default area) is considered a non-empty value > then that sounds fine. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#913 issuecomment-278310892>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ARTwq_ ouG5RKAUCMPK4iPaCPQKZcxQ4Pks5raa_MgaJpZM4L5m0s> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#913 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnOPSnPl22-XpUSvYhFGVJvBGMitum9ks5radpogaJpZM4L5m0s> .

-- Len DiMaggio (ldimaggi@redhat.com) JBoss by Red Hat 314 Littleton Road Westford, MA 01886 USA tel: 978.392.3179 cell: 781.472.9912 http://www.redhat.com http://community.jboss.org/people/ldimaggio

[AdamJ]

@maxandersen @Mgranfie @ldimaggi The default Area or "/" carries the name of the Space. For instances, Space "BalloonPopGame" automatically creates a default Area called "BalloonPopGame". That is how it would display to a user to make things easily distinguishable.

sample path -> //Fabric8/BalloonPopGame/BalloonPopGame

[pmuir]

The detail view contains a dropdown that displays the current Area of the Work Item.

The user can change the Area value of a Work Item by using this typeahead dropdown that contains all Areas of the current Space.

It's either a typeahead or a dropdown (confusion as both terms are used).

It is not possible to set an empty value for the Area.

I would also suggest having an acceptance criteria such as "by default, the '/' area is selected for the user".

Another functional acceptance criteria should be: "It is not possible to add, remove or update areas from the Work Item detail view." - this is in case people thing that you can somehow modify the areas from this screen.

• UX Wireframe for Areas

This wireframe is substantially incorrect.

• Callout (1) in the top left: the platform displays the current space only here. The {organization|user} name is not displayed here if the planner is open. The area is never show here.
• Callout (1) in the detail view. The user story specifies this as a typeahead, the mockup shows a dropdown - needs resolving (personally I prefer a typeahead, but regardless choose one or the other).
• Callout (2) is discussed but not identified on the screen.

@maxandersen @Mgranfie @ldimaggi The default Area or "/" carries the name of the Space. For instances, Space "BalloonPopGame" automatically creates a default Area called "BalloonPopGame". That is how it would display to a user to make things easily distinguishable.

In the UX, the default area in a space is / and is NOT the name of the space (note that the backend may not implement the data model exactly this way, but that is neither here nor there for the UX).

sample path -> //Fabric8/BalloonPopGame/BalloonPopGame

This sample path is incorrect, the area does not appear in the path today, as you cannot today navigate to an area

In general, I think there is some confusion that an area is a navigation element - it is not. An area is a filter that can be applied in the planner.

@michaelkleinhenz is working on a strawman for the URL structure, which will help make the URL structure clearer - in particular which elements can appear in the URL path vs the URL query string.

[Mgranfie]

inline...

On Wed, Feb 8, 2017 at 11:47 PM, Pete Muir ***@***.***> wrote: The detail view contains a dropdown that displays the current Area of the Work Item. The user can change the Area value of a Work Item by using this typeahead dropdown that contains all Areas of the current Space. It's either a typeahead or a dropdown (confusion as both terms are used). It is not possible to set an empty value for the Area. I would also suggest having an acceptance criteria such as "by default, the '/' area is selected for the user". Another functional acceptance criteria should be: "It is not possible to add, remove or update areas from the Work Item detail view." - this is in case people thing that you can somehow modify the areas from this screen. - UX Wireframe for Areas <https://redhat.invisionapp.com/share/XCA839ET9#/217730372_Areas_-_002> This wireframe is substantially incorrect. - Callout (1) in the top left: the platform displays the current space only here. The {organization|user} name is not displayed here if the planner is open. The area is never show here. (mg) Pete are you saying that the Area you are in is never displayed

anywhere for context? That would seem odd to me based on the desc. that Todd gave. ie: I am working int he office/excel/mobile/ios, mobile/ios being the areas. Would I not want/need to see and know this for context? or are you saying that a user can work in more than one area at time?

- Callout (1) in the detail view. The user story specifies this as a typeahead, the mockup shows a dropdown - needs resolving (personally I prefer a typeahead, but regardless choose one or the other). - Callout (2) is discussed but not identified on the screen. (mg) these are also being revised by Adam to accommodate hierarchy/paths

of the areas.

@maxandersen <https://github.com/maxandersen> @Mgranfie <https://github.com/Mgranfie> @ldimaggi <https://github.com/ldimaggi> The default Area or "/" carries the name of the Space. For instances, Space "BalloonPopGame" automatically creates a default Area called "BalloonPopGame". That is how it would display to a user to make things easily distinguishable. In the UX, the default area in a space is / and is NOT the name of the space (note that the backend may not implement the data model exactly this way, but that is neither here nor there for the UX).

(mg) Adam this was a discussion that you had with Todd? As I understood it and Adam correct me here... "/" is the default area and until a user creates an area it is surfaced as the same name as the space.

sample path -> //Fabric8/BalloonPopGame/BalloonPopGame This sample path is incorrect, the area does not appear in the path today, as you cannot today navigate to an area In general, I think there is some confusion that an area is a navigation element - it is not. An area is a filter that can be applied in the planner. @michaelkleinhenz <https://github.com/michaelkleinhenz> is working on a strawman for the URL structure, which will help make the URL structure clearer - in particular which elements can appear in the URL path vs the URL query string.

(mg) great keep us posted!

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#913 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARTwq5zNW-P1PDqNnps4h_1RQrcj934Mks5rappXgaJpZM4L5m0s> .

[AdamJ]

@pmuir @Mgranfie

Callout (1) in the top left: the platform displays the current space only here. The {organization|user} name is not displayed here if the planner is open. The area is never show here.

• I'll remove any platform references, given that there are no other UX portions for that. It'll just stay as an empty bar for the time being, given that it is not part of Planner. At some point, we will need some sort of identifier to inform the user as to what Area they are currently in. Not doing so could become a pain point.

Callout (1) in the detail view. The user story specifies this as a typeahead, the mockup shows a dropdown - needs resolving (personally I prefer a typeahead, but regardless choose one or the other).

• I've adjusted the wireframe to show this as an input box where once the user clicks into it and activates the input, a selection of available items will appear.

Callout (2) is discussed but not identified on the screen.

• Fixed in the updated wireframe

In the UX, the default area in a space is / and is NOT the name of the space (note that the backend may not implement the data model exactly this way, but that is neither here nor there for the UX).

• In emails with Todd, it was decided that the default Area will have the same name as the Space. Similarly, the default root of Iterations will also carry the name of the Space. I.E. Space 'Foo' has default Area and Iteration of 'Foo'. These are just visual queues - the data can be stored any way that is seen fit (such as '/Foo' or 143ad-75cd2-fe32A-88b1c-dde19).

[pmuir]

(mg) Pete are you saying that the Area you are in is never displayed
anywhere for context? That would seem odd to me based on the desc. that
Todd gave. ie: I am working int he office/excel/mobile/ios, mobile/ios
being the areas. Would I not want/need to see and know this for context? or
are you saying that a user can work in more than one area at time?

In the MVP areas are only supported in the planner, they are not supported in other areas of the platform, as this is not designed or architected out. Therefore areas are always displayed to the user in either the work item they are looking at or the filter they apply to a list view.

We may well want to expand areas to other parts of the platform, but we don't need that as part of the MVP. When we expand areas to other parts of the platform, then we can look at how it shows up in the platform UI.

In the UX, the default area in a space is / and is NOT the name of the space (note that the backend may not implement the data model exactly this way, but that is neither here nor there for the UX).

In emails with Todd, it was decided that the default Area will have the same name as the Space. Similarly, the default root of Iterations will also carry the name of the Space. I.E. Space 'Foo' has default Area and Iteration of 'Foo'. These are just visual queues - the data can be stored any way that is seen fit (such as '/Foo' or 143ad-75cd2-fe32A-88b1c-dde19).

Ok, that's fine by me - I'm of the opinion that / is a better default area, but this is a great one to A/B test down the line and see what users prefer :-)

[AdamJ]

@nimishamukherjee I created the wireframes and interactions for this, so I'll be pairing up to help with any questions/comments/concerns. Just let me know when you'd like to go over the wireframes - I'm available at all sorts of hours :-)

[AdamJ]

@nimishamukherjee is there any progress/info on this Issue? Have any more questions come up that need to be looked at? Thanks!

[debloper]

Functional tests pending