Hi @NedLindau
Yes, they are currently lumped into separate menus. That is also exactly my point. This navigational change is being driven by wanting to (in Atlassian’s words) “Create a consistent appearance and user experience across all our products, making it smoother to switch between [various Atlassian products]”.
Since you are redesigning to make switching smoother, why perpetuate the point of friction by pigeonholing certain functionality into being part of an “apps” menu? Can apps not be part of the smoother switching too?
Yes, it is how it works today, and as above, I would argue that it is a paradigm to be avoided. (And I thought it was also the paradigm behind this entire redesign.) The user wants to create a diagram, period. Why should the user need to know that this is an “app”, any more than the customer should need to know that they need to switch to Jira before they can search for Jira issues in the new proposed system? (Aren’t both just implementation details?)
And if apps should be treated separately, why do certain Atlassian apps (for example, Team Calendars) get special treatment and get elevated out of the “app” menu into prime sidebar real estate, while third-party apps cannot display there? The reasons mentioned many moons ago have been lack of screen real estate and possible contention with many apps installed, but it seems like the proposed changes to showing/hiding sidebar items already solves those problems.
At the end of the day, Solutions Partners sell a combined set of products that work together, including Jira, Confluence, and third-party apps. The entire goal of this change seems like it is to harmonize switching between products. While you are doing this work, why not allow Marketplace partners to benefit as well, instead of enforcing the status quo? Instead of siloing apps simply because they come from a third-party vendor, why not allow vendors (and users) to organize their apps’ touchpoints in appropriate locations based on functionality?
I am personally a fan of the Confluence DC system of having (for example) a sticky Space Tools menu at the bottom of the sidebar. Not sure how that would transition into your new paradigm. My answer also depends on how you decide to implement the sidebar navigation.
For example, when a user navigates to a page, will the page tree render as automatically fanned open and already scrolled to highlight the current page that the user is visiting?
If so, the global space features will almost always be hidden.
If not, users will presumably have a hard time figuring out how to navigate laterally through content, especially if they have to manually retrace the breadcrumbs in the tree.
How is this implementation envisioned?
Cheers,
Scott