RFC-66 Quick Action Revamp

[AhmudAuleear]

Summary of Project:

We are redesigning the Quick Actions Menu within the Atlassian ecosystem to improve scalability, usability, and performance. The new design consolidates actions and apps into dropdown menus, streamlining user interactions, enhancing discoverability, and ensuring a consistent experience across all Atlassian products. This redesign addresses the growing complexity and clutter in the current menu, aiming to provide a more efficient and user-friendly experience.

We are focused on modernising the Issue View, and a key strategy is reducing clutter to improve ease of use. These changes mark the first milestone for the Quick Action Menu. We are committed to future milestones and recognise the importance of marketplace apps within the Issue View.

• Publish: September 26th, 2024
• Discuss: October 10th, 2024
• Resolve: October 15th, 2024

Problem

The Quick Actions Menu has become cluttered and inconsistent due to the addition of numerous first-party (1P) and third-party (3P) actions. This clutter has led to cognitive overload, complicated task completion, and negatively affected performance. Users struggle with discovering and efficiently accessing the actions they need, resulting in reduced ease of use. The growing scope of objects, products, and integrations within the Atlassian ecosystem necessitates a scalable solution to maintain usability and consistency.

Proposed Solution

To address these issues, we propose the following changes to the Quick Actions Menu:

Unified Add Content Dropdown: This dropdown will consolidate all 1P actions, reducing the clutter in the main menu and making it easier for users to find and use these actions.

Apps Dropdown: Groups all 3P apps into a dedicated dropdown.

If a user has no apps installed they will see the following options:

If a user has apps installed within their instance, they will see the following options:

Impact

User Experience: The redesigned menu will simplify user interactions by reducing cognitive load and making actions easier to discover and use. The screenshots provided offer a visual guide to the new menu structure.

Ecosystem Impact: Marketplace partners are not expected to make any changes to their apps. The current app extension point remains and we show the app in a new location.

Asks

While we welcome any feedback on this RFC, we are particularly interested in learning more about the following:

• How might we improve the discoverability of apps within this new design?
• What is the expected order of the apps within the app dropdown menu?
• Is there any impact on your app that you would like us to consider?

[david]

Oh, here we go again. Throwing apps into a general “hide this crap over here” bucket.

Please take a look at RFC-59 and learn from everything that people wrote over there as the exact same critique for this. I’m not going to repeat myself here.

Questions:

• Do Confluence whiteboards and Confluence databases not count as “Apps”?
• Or is it just third-party vendors apps that get the second-class treatment?

[remie]

@AhmudAuleear thank you for the RFC.

Would it be possible for Atlassian to be consistent and follow the UI changes proposed by other teams in which the user is given the option to select which apps should be immediately accessible instead of putting every app in the dropdown?

As previously mentioned in other RFCs with regard to UI changes: the stated purpose of many of these changes has been to provide a better more unified and seamless user experience for customers. Making a distinction between 1P and 3P content does not seem to fit this goal, as this difference is unimportant for the customer. The customer just wants direct access to content they are using on a day-to-day basis.

Putting all apps in a separate drop down is antithetical to what Atlassian says it wants to achieve. So either you should update your goal, or update your UI proposal.

[tobias.viehweger]

Hi Ahmud,

thanks for the RFC, this change was already discussed a bit in this thread, with my main gripe being the change in button text: Major (upcoming?) UI change in how issue content is accessible to users?

I understand you are looking to declutter this area (though I agree with @david and @remie that the 1P / 3P distinction is strange for users, who don’t necessarily understand what is an app and what is built in). I also would’ve hoped for more customization options for users - e.g. pinning of buttons, so users can decide about their preferred “one-click” actions - the proposed solution adds one more button click for each interaction with our app. What I would hope to get fixed though is the naming of the buttons, since that seems to change and would potentially confuse users. Our issueContent module looks like this:

"jiraIssueContents": [{
    "key": "teams-conversation-content",
    "name": {
        "value": "Microsoft Teams",
        "i18n": "teams.issueContentTeamsQuickButton"
    },
    "tooltip": {
        "value": "Start conversation",
        "i18n": "teams.startConversation"
    }
}]

The current behavior is, that the “name” attribute controls the label on the issue content area itself:

The “tooltip” attribute (though the naming is unfortunate), controls the “action” button above:

However, in the new UI (with the “Apps” dropdown), the buttons in the dropdown used the “name” attribute instead of the tooltip attribute. That would be our biggest ask, to restore the naming to be correct to not confuse existing users if they are looking for “Start conversation”.

Thanks
Tobias

[remie]

@AhmudAuleear

The Quick Actions Menu has become cluttered and inconsistent due to the addition of numerous first-party (1P) and third-party (3P) actions. This clutter has led to cognitive overload, complicated task completion, and negatively affected performance. Users struggle with discovering and efficiently accessing the actions they need, resulting in reduced ease of use. The growing scope of objects, products, and integrations within the Atlassian ecosystem necessitates a scalable solution to maintain usability and consistency.

Take one second to look at your problem statement.

How is “let’s put everything between two drop down buttons, with a distinction between 1P and 3P content that is only relevant to us and not the customer” a viable solution for this problem?

The only way to combat clutter and allow users to discover and efficiently access the action they need is to A) enable customisation of the view and B) create a single searchable drop down that provides direct access to all content and is preferably ordered by usage.

Can you please just for once try to follow proper UX design best practices?

[AhmudAuleear]

@david

RFC-59

Hey @david,

Thanks for your response. I’ll take a look at RFC-59 to review your feedback.

I understand the general theme of your feedback and recognize the frustration around the perception of apps being “hidden” in a dropdown. Our goal is to simplify the issue view and make core actions easier for all teams to use. We are rolling out several changes that move less used first-party features behind dropdowns. One of the largest themes of feedback from customers has been the cognitive overload caused by presenting all options at once and clutter.

As a PM, I’m constantly reminded by Atlassian Product leadership how important marketplace vendors and apps are to the Atlassian ecosystem. We don’t make these decisions lightly, and we carefully consider your feedback in the process and when prioritising our roadmap.

[AhmudAuleear]

Hey Remie,

Thanks for the response. Yes, those requests are functionalities we are considering for future milestones. We are committed to investing in improving this experience. We have ideas around allowing customization and better ways to display/order options in the dropdown.

[AhmudAuleear]

Hey @tobias.viehweger ,

I’ve passed this along to my tech lead to explore further. Once we have a better understanding of the effort and scope required for this fix, I’ll make sure to prioritize it accordingly and let you know of the outcome.

[remie]

@AhmudAuleear

Yes, those requests are functionalities we are considering for future milestones. We are committed to investing in improving this experience.

I’m going to be very honest with you: we’ve been hearing this on almost every RFC of the past year. The harsh truth is that in the end, the current team will have delivered their objective, met their OKRs, get promoted and will continue with the next shiny new thing. The turnover of Atlassian staff (either between teams, or complete exits) makes it almost impossible to make good on this promise.

So please do not make any promises that Atlassian can’t keep. Either you implement it now, or just be open about it never being implemented.

[MattiaLomazzo]

Hello Ahmud,

Thank you for replying to the feedback you’ve received so far.

I have a very simple question that I ask you to answer as one of your dumbest possible Jira users, currently on the issue view in your example.

What happens when I click on the example “Tempo” in this app drop-down? Will I receive a pack of Tempo tissues? Am I shown a time limit for how fast I can work? Will I be shown the weather forecast?

It is the same for any other app listed in this dropdown. How will a user make the connection between the action they need/want/are allowed to perform and the app names listed?

[leonardo.diaz]

Hello @AhmudAuleear ,
Thanks for this RFC.
Why not let platform/tool administrators decide which apps are seen?

I think sometimes we forget that we are in a B2B environment where there are some very powerful users (admins) who like and need to configure the tool to the user’s liking.

[remie]

@AhmudAuleear I guess the lack of response here proves my point