View/Selecting the active Space [13]

[michaelkleinhenz]

Description

As a user, I want to see the current space context and want to be able to switch to a different space context.

Functional Acceptance Criteria

1. The user can always see the current space name to be aware of the current context.
2. The user can always switch the current space by selecting a space from a control.
3. Switching the space refreshes the current view according to the new context.
4. If the current view is not available in the new space context (example: a detail view of a work item), then the work item list is displayed.
5. If the current view contains unsaved changes, switching the space context requires confirmation.

Note: the current criteria only covers a "simple" list of spaces known to the system. There will be later stories that replace/flexify the experience for selecting the space context. Note also that later, the context of lists/views could also be not only spaces but also users, areas etc.

Non-functional Acceptance Criteria

1. The "switch space" control is easily accessible from anywhere in the system UI.
2. All view refreshes are done in-place.

   Dependencies

3. Userstory #357

[maxandersen]

should we cover something about how the URL is affected by this ? (in PDD is requirement of every page being linkable/have a stable url).

Also, I'm not sure I follow what a "switch project" control means ? Is it just that for now we don't have something better (search) and a menu with all listed projects will work initially ?

In addition I think it is worth stating that project context would just be one of many ways to view a list of work items - other "view contexts" would be User, Team, Area, A query, etc.

[michaelvirgil]

@maxandersen I view the project context more broadly. Conceptually the project has an associated backlog and in addition maintains context for other aspects of planning, communication/reporting and execution.

This can include planning aspects like association to a Portfolio, Program, Product and release planning including estimation. A project context would also conceptually maintain data and context for things like execution; Agile planning, backlog management, backlog grooming, iteration/Sprint planning, metrics and reporting on execution.

From a users point of view, I would expect the system to manage all of this for me... I set the context to a specific project and everything I do and see is within the context of this project.

The underlying implementation (based on your comment of the project being a view into the backlog) should not be reflected in the user experience. As a user I shouldn't care if the entire system has a single backlog - all portfolios, all programs and all projects etc. As I know you know, there are other issues with a single data source in that case around multi-tenancy, security etc...

[michaelkleinhenz]

@maxandersen I would think the stable url is a different story or part of a list of "ambient requirements" that are in effect for all stories.

For the control: I think we should start with the simplest solution, a dropdown somewhere in the page header. We'll definitiely need something more flexible later, possibly also something like a quick-access with "starred" projects or something.

The context may be an own epic later, I read the PDD that it should for example also possible to see personal worklists that cross all projects of a user. This also adds to the epic "view contexts".

[nimishamukherjee]

Based on our current implementation, a user can exist in ALM without a project. We can look at this as the starting point. UX could consider following scenarios:

1. User does not belong to a project
2. User belongs to a single project
3. User belongs to multiple projects

We would need to bring in privileges at a later stage. Based on the user privilege, what is it that the user can do/view in a project.

[michaelkleinhenz]

Note: added DoD and ambient requirements to devdoc PR.

[maxandersen]

@michaelkleinhenz what I mean is that I would consider this story a fail if the url is like almighty.io/some/weird/nesting/project?name="My%20Project" :)

[maxandersen]

@michaelvirgil one worry I have is that we all might be talking about projects at different levels.

i.e. github has project = one repo (simple, but limited), jira has project = a thing in a sea of other projects - backlogs are queries not restricted to a single project (very powerful), vso has project = a project with no or very linking to other projects, but has areas to subdivide the project (somewhat powerful, but a walled garden).

Of all the above I think Jira has a more flexible model than the others - but the security model gets complicated.

And in all of these it at least to me very heavily influences the user experience AND the implementation behind it.

i.e. in jira you don't really choose a project anymore, you end up with a scrum/kanban board.

[ldimaggi]

Are our (ALM) projects more or less containers - where each contains multiple users, multiple repo's, etc.?

[Mgranfie]

The selection of the project will happen in the same location as the create project.

[maxandersen]

Are our (ALM) projects more or less containers - where each contains multiple users, multiple repo's, etc.?

Yes to them being containers.

But I would not say they contain users, users have access to the projects and the repository are being used by a project.

[sanbornsen]

@Mgranfie Can you please add the project design URLs here? Designs that you shared on the last UX meetup.

[tsmaeder]

12 points.

[baijum]

8 Points

[michaelkleinhenz]

This issue was moved to fabric8io/fabric8-planner#650