RFC-59: Upcoming changes to Confluence navigation

[scott.dudley]

Hi @NedLindau

@NedLindau

This is all well and good, but it is at odds with the decision to lump “Apps” into a separate menu (or two separate menus, as proposed).

Want to make sure I understand this one. Apps are already lumped into these two separate menus today, right? Or am I missing something in your comment here?

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?

If a user wants to (say) create a diagram, why do they have to realize that this functionality is an “app” and that they have to go some place special to do it, rather than going to a logical location that makes sense given the context? Isn’t that loosely the opposite of what this harmonization is supposed to accomplish?

Want to make sure I understand this one. Isn’t this how it works today? For example, to create a Gliffy diagram, I have to know that Gliffy is an app and know how to create it from within a page.

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 would also suggest that Atlassian think about whether there might be a place for sticky scrolling here for certain sidebar elements. For example, if a space has a large content tree, what happens when the sidebar is scrolled? Does the top “nav” section remain in place, or does it disappear (partially or completely)? And would the users have to scroll down to the very bottom of the space content to find the “space apps” menu, or would it remain always visible without scrolling?

Great suggestion! We’re thinking about this for sure. Currently, we will “stick” the space name when a user scrolls downward, but all of the product/global items about that will scroll off the screen. Is this how you’d expect it to work?

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