Hi @Amanda Sacks - as a completely blind user of Jira, the current new view (opening an item no longer replaces the current tab content with that item) makes the item a lot harder to read, and the view is a lot more "noisy." I'd love a setting to turn this off, so that when I click an item it opens that item in the current tab; replacing the search view I used to click the item.
Thanks a lot, for fielding all of these comments, and for your help!
This is a terrible change that makes devs and analyst more complicated work as in the old view we could do almost anything and now I need to go way down to make a simple change on a field and the panel is very narrow and cant be extended very much. @Amanda Sacks Jira managed to make our lives more difficult
Atlassian Team members are employees working across the company in a wide variety of roles.
June 29, 2026 edited
Hi everyone,
We've started releasing the modal and the navigation arrows via phased rollouts (if you don't have them yet, you will very shortly).
You now get to choose how you view your work in the List, in a modal or the Preview Panel.
A few notes on the work item modal:
It looks and works the same way as the modals on other Jira views (for example, the Board)
It shows both work item columns side-by-side, rather than stacking them, which happened in the Preview Panel on small screens (e.g. 14") and at narrow widths, and created a cumbersome experience
To open the modal for the first time, use the button in the top right of the Preview Panel. Your choice to view your work in the modal or the Preview Panel will persist across Jira views within the same session, so if you view a work item in a modal on the Board, opening one on the List will automatically open it in a modal too.
We're still working on making that choice persist across separate Jira sessions. Some of you have said an extra button is still extra clicks. Once cross-session persistence lands, your choice becomes your default and you won't be doubling up on clicks each time. We wanted to first roll out the modal to give you the choice of how you view your work items, and the persistence piece is coming soon.
Notes on the arrows:
You'll find these in the top right of the work item, whether you open it in the Preview Panel or the modal. You can still use the J and K keyboard shortcuts.
We'd love to hear how you're getting on with the new features, so please do share.
Last but not least, on deprecating the Detail view: across our feedback sources, we've heard concern that the modal and arrows may not support every workflow the Detail view did. We're looking into that separately to understand where any gaps are, and we'll come back to you with the direction we're taking. Hold tight for a little longer (and thank you for your patience so far!).
Hi @Amanda Sacks - I was having a hard time visualizing what you were describing. Next time consider including screenshots?
Luckily I seem to have access to one site on the Old View, another on the first Preview Panel try, and the new Preview Panel with Modal, so I've taken some screenshots with my 2021 16" MacBook Pro which has a screen resolution of 1728x1117 at 254ppi, so a pretty big screen. Chrome windows were maxed out to edges of screen.
Hopefully this will help illustrate 1) where the new features are that you're describing, 2) why many of us are not happy with the initial Preview Panel release, or the Modal "fix".
Old List View
Old Detail View
Preview Panels - Take 1
Preview Panels - Take 1 - Detail View doesn't let you go prev/next
Preview Panels - Take 2 - List View
So I know @Arvin Bryan San Pedro Gaw likes the wider Issue List view, but sorry that is ONE person out of over 95 people here who really don't need all that extra space for the Issues List.
I think what might help is if (as somebody already asked) you could allow the preview-panels.panel-splitter to slide over to the left past 50% so we can use 85% or even 70% of the screen for Detail view?
Preview Panels - Take 2 - Modal Detail View
So, ok, sure, with the Modal, you can see much more of the Issue Details. About 70% of the screen width is available. So sure, this approximates the old Details view, losing about 30% of screen real estate.
It's frustrating though because the Issue List is right there, grayed out. It feels wasteful to be hiding that information, graying it out or obscuring it with the modal.
Anyways I'm sure others, once they see the difference, will have some ideas of their own.
@Amanda Sacks The supermajority of the feedback to this change has been "please bring back the detail view." Atlassian has chosen the "fail forward" course instead. (Please note I employ the term pejoratively in this instance.) In your posts, both the original and the subsequent updates, you have assiduously avoided explaining why Detail View was being taken away and why Atlassian won't revert the change and bring it back. Would you please address that elephant? It might help were you to give your consumers a solid line of reasoning. Atlassian can, of course, choose not to do so; that too will speak volumes.
To be fair, it isn't really accurate to say this isn't something for which anyone asked. There are people like I that didn't find the Detail view helpful and, instead, found it to be limiting and "plodding" from a workflow standpoint when hopping between projects and work items.
That said, I'll grant that a slow rollout vs. full replacement would have been the better path. Nicer to give users the ability to choose familiar/new views for a time until new view has feature/UX parity with legacy view and gains adoption by users.
@Amanda Sacks This is all fine an dandy, but as mentioned above as well is not really what it seems everyone wants. We use the "old list view" as mentioned above more than anything else. The ability to see and interact with the list of tickets, click on each item to show the details using more of the screen, but still able to move to the next ticket as it was shown on the left side worked very well for us.
Now this is similar to the preview panels, which has been forced to grow on me. As was said earlier, and it might have been by me as well when comments started on this page, that is seems to be a very simple fix to just allow for more than 50% of the screen to be used in the preview panel. If I could move the preview panel and make it wider it asks very similar to the views taken away from us. Said very well in this comment:
I think what might help is if (as somebody already asked) you could allow the preview-panels.panel-splitter to slide over to the left past 50% so we can use 85% or even 70% of the screen for Detail view?
To me that seems like an easy fix to push out Then you can figure out what will work well for everyone The modal view seems useless to me as I can't select another ticket without closing out the one that I am on or moving forward or back with the buttons. I need for both to be active sides I see promise in the side panel view, but I need the ability to move the preview panel more than 50% of my screen.
Now that I'm in the office with my large Dell P3421W ultrawide monitor, I thought I'd take a few more screenshots.
Chrome fully expanded in a 3440x1440 resolution screen
So... it's funny, the new Modal button's tooltip (which is currently broken) is supposed to say "Expand" when you hover over it. That does not look expanded to me.
But hey, you can kind of see the list behind it. If only it wasn't grayed out.
As I played with resizing, I noticed that when I made the window quite narrow, the modal kept the left and right-sides split (and again it still maxes out at 50%). Interestingly, in full-screen Details mode and in Preview Panel, the right-hand dynamically stacks the right-hand content.
Obviously this is a silly edge case, but it is interesting how the Modal View is feels just a little... incomplete?
Modal
Preview Panel
Detail
It did make me wonder, WHY Modals?
I mean, historically Modals were pop-ups, right?
I did the lightest of Googling (why modals), and found some articles:
Here are some other perceived “negatives” I’ve heard about them:
🛠 Modals are hard to build:this one still comes up still from time to time, despite the libraries and other modern resources we have in the broader community 🤷♂️. I’m not sure what it is exactly, but modals come with a lot of considerations around positioning, sizing, scrolling, Z-axes, etc. that sometimes give engineers headaches.
🛑 They prevent the user from immediately interacting with whatever they want to:I suppose this is technically true, but I don’t see this as an inherentlybadthing. Rather: Modals are one of the (many) interaction design methods you can use to focus attention and to bring clarity to what information is timely and important. It’s a form of progressive disclosure that reallycanbe reactive to interface use, even if it’s often not the most most visually “elegant.”
🤦 People confused “modals” broadly with “pop-ups” specifically.Most modals I design areuser-initiated: they are “asked” for and react to user needs. But a lot of us are plagued by memories of the Internet past — and in some cases, the present — where “modals” are oftensurprisesto the user. These “pop-ups,” rather, are often modals designed to convince you to do something — e.g., sign up for a newsletter, give the vendor your phone number etc.—and should be used sparingly, at best. But we shouldn’t conflate these with modals that respond to user intent.
And from the article advising modal caution:
Modals are overused on the web today. Looking closely at their use cases, it is easy to realize there are misconceptions around their proper application.
Modals are a strongly discouraged UX pattern. By design, they interrupt a user’s workflow. When a modal is active on a page, the user is blocked from interacting with the page outside the modal and cannot return to their workflow unless they complete the modal task or dismiss it. While modals could be effective when used correctly, they should be used judiciously to limit workflow disruption.
Modals grab users’ immediate attention. They are meant to be bold and should be reserved for cases that deserve users’ undivided attention.
Hey look. It's 2026. I'm sure there's a VIGOROUS and wonderful debate about Modals in the UX community. Apparently Atlassian loves them.
I just am not sure they're the right "fix" here.
But I'm no UX designer. Just a Jira Admin trying to keep my users from screaming at me if/when this reaches my site that thankfullyis on Bundled Release Track (if you are on a Premium Plan or higher, you should do this), so we've been spared... for now.
140 total messages (1 original post + 139 replies) on the blog article "Preview Panels will soon replace the detail view in Jira's List view." The thread has been intensely active. The overwhelming sentiment is negative, with a small but notable minority expressing support.
...
Community Sentiment Breakdown
🔴 Dominant Theme: "Bring Back Detail View" (~80%+ of comments)
🟡 Key UX Complaint: Preview Panel Capped at 50% Width
The thread tells a clear story: the community overwhelmingly wanted Detail View preserved as an option, Atlassian removed it without public explanation, and the iterative fixes (Preview Panel → Modal → Navigation Arrows) have not addressed the core complaint. The most pragmatic suggestion — letting the panel splitter exceed 50% — has broad support but hasn't been acknowledged by Atlassian.
Many of you have noted that this change adversely affects large number of your users and their time. It might be worthwhile to file a Support Ticket and detail that impact in as concrete and subjective numbers as possible, because that (should) feed into the UIS.
I can't proveit had any effect, but I also tracked a lot of this information when Atlassian moved the Status Button last year, and then rolled it back:
141 comments