Show all posts
12 months ago

Projects-Teams selector redesign

Our upcoming release (v.3.10.2) will contain a complete redesign of the projects-teams selector. To reduce complexity, we've made the selector a part of views (rather than a global setting found on the top bar). It will now be clear if a view is displaying data from the default project-teams selection made by the owner of the view, or data from the projects and teams selected by you.

Old version:

globalContext_h

New version:

globalContext_moved_h

We made these changes to solve two main issues. The first is that data in views would unexpectedly change because of unintended projects-teams selections. This happened when you navigated through views with and without predefined selections by the view owners. It was sometimes unclear why certain projects and teams were displayed in certain views.

The second issue would occur when users collaborated on views. It was often unclear for users that they were seeing different data than their teammates because they had set a different selection of projects and teams. To fix this, we've made the projects-teams selector as straightforward as we can. You will now always know what data you're looking at on the view and why.

By default, a view will show the selection set by the view owner in View Setup. 

You can still make a view display data from any projects and teams that you need to see. When you modify the set of projects and teams shown on the view, the selector will be highlighted.

viewModeWithUserContext_revert

These changes are applied only for you; other users will still see the view with the predefined projects and teams selected by the view's owner. 

Once you set projects and teams for a view, your selection will be saved for that view. You can easily revert back to the predefined selection by clicking the revert button.

viewModeWithUserContext_revertAction_h1

If the view's owner hasn't set a projects-teams selection for the view, then the revert action will not work because there is nothing to revert to.

For more information, visit the Project and Teams Selector article in our User Guide.

  • Florian Schmitz

    Seems like the major annoyance experienced from day one of using TP gets finally fixed, thanks! 🙂

  • Rob Forster

    Fully agree. Major annoyance and confusion for our team members is finally resolved. Thanks!!

  • Carl Nygard

    What happens if the view does not have project/team settings, and then I restrict that view to a specific project. If I move to another view that also does not have project/team settings, will my project restriction also take effect, or will I have to re-pick the project on every view?

    My work methodology actually depends on the global nature of the project settings. I’ve created a set of views that provide me a workflow for any project, so each view does not restrict to a specific project. Once I set my project restriction, I can execute my planning workflow my walking through the different views, and they all show me the same project.

    Based on your changes, it seems like now I have to duplicate this set of workflow views for each project, which doesn’t really work when I’m trying to plan for a team sprint and need info from multiple projects. Otherwise, I have to continually choose the project(s) every time I switch a view when executing my workflow?

    Perhaps you can provide both? The previous global setting that would override any individual choices made on an individual view? If global setting is unrestricted, then use the View restrictions as currently implemented.

  • Filipe Nevola

    I have been using in this way too. Let’s wait the answer.

  • Alla Pogotskaya

    Thank you for the feedback. As you’ve mentioned the workaround is to have duplicated views for each Projects-Teams selection or setting Projects-Teams when you navigating to the View. We did such redesign to solve a class of very annoying usability issues. And now we are gathering feedback to determine if we need more changes in Projects-Teams selector and what kind if so.

  • Ryan

    We’ve been using TargetProcess for over a year and it continues to be a struggle to get the team and clients to adopt it. We’ve spent a lot of time trying to understand the near universal resistance towards using it. The majority of what we’ve identified relates to the the selector and frustration over what “context” they’re in. Unfortunately, these changes didn’t address the underlying reasons that there were and will continue to be confusion.

    The original and new selectors aren’t actually setting a “context”, they’re setting a data filter on the view, report, or dashboard you’re looking at. As others have suggested in the UserVoice forums, if we had the ability to set a true “context” that would filter what is presented in the left menu (as well as providing an first level of filtering of the data you’re viewing), it would simplify the user experience greatly. Selecting different views shouldn’t change the context in which you’re currently working, but this would occur even with this new selector. Following this approach, the left side options would remain relevant to what you’re working on at a given moment and would be less overwhelming to work with. It’d also avoid the need for the workaround suggested for Carl’s situation, which would introduce its own usability problem by having duplicated views listed that only differ by filter assigned to them.

    The other usability issue with the selector is the way it displays what has been selected. The project/team initials don’t make it easy to know at a glance what has been selected until you’ve memorized them. This is a challenge for those of us who have several projects for numerous clients. It’s made worse when multiple selections have been made as not all are shown. Other products and sites handle faceted searches and multiple filters in ways that strike a balance between compact and clarity.

    TargetProcess is very powerful, but its capabilities are hindered by the UI. It’s a shame, as we’re now beginning to evaluate other products that aren’t as feature-rich but are usable.

  • Michael Dubakov

    @disqus_0tzo8yTA0h:disqus
    We’ve just started to work on Workspaces and the concept is very similar to what you’ve described. I hope next year we will have it in Targetprocess. Basically, every Workspace is a separate instance of Targetprocess with a unified users management mechanism. So it will be possible to setup, let’s say, Workspace per Department and enjoy simplicity.

    As for Project/Team initials, I don’t have a good solution right away. It is hard to display whole names, since it will take too much space. However, we will think about that.

  • Ryan

    @mdubakov:disqus Thanks for taking the time to reply. The “Workspaces” feature does sound promising and a move in the right direction. It’s the kind of solution we had hoped the selector redesign was bringing, but unfortunately that wasn’t the case. Our organization will need to move to another product in the meantime since these changes have made TargetProcess unuseable for our needs. Like Carl, we set up general views that could be used for any project, but TP can no longer be used in this way.
    I can’t speak for other organizations, but the vast majority of the time we want to select either a single project, a single program, a single team, or just show everything.

  • ILLID

    test test

  • ILLID

    co

  • ILLID

    hfghfh

  • ILLID

    Hi all!

  • ILLID

    Hello world!!!

  • ILLID

    Hi there!!!

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy