Rethinking Issue View Field Configuration

[Ahmud Auleear]

Hey Admins, 

We've heard consistent feedback that the Issue View can feel cluttered and overwhelming, making it difficult for people to efficiently find and update field. Too many fields, disorganised layouts, and excessive empty fields contribute to cognitive overload for users, while admins face complex processes to configure the Issue View to suit their ICs' workflows.

While we're still in the early stages, we're exploring ways to make the Issue View simpler and more intuitive.

We are considering ideas such as inline editing from the Issue View, removing the need to access configuration screens and enabling real-time adjustments. We're also streamlining field grouping by combining some fields and empowering end users to personalise their views without impacting others.

I've uploaded a high-level concept that is not validated but rather a concept to help you envision a potential solution.

If you have any feedback, positive or constructive, or would like to discuss this problem further, I'd love to connect via Calendly.

Feel free to leave a comment as well!

Thanks, 

Ahmud 

[Tim Eddelbüttel]

Just my 2 cent...

• Add theming support to Jira
• Make it available for app developers.
• Create a "Jira Classic" theme

Problem solved as you will never satisfy everyone as there is no one view fits everyone!

[Dirk Ronsmans]

Hi @Ahmud Auleear ,

Great that this is becoming an area of interest.

Looking at it from a JSM point of view there are some major enhancements possible imho.

• Not linking Request Type configurations to Screen configurations would be one, as not all customers use request types (or even a portal) and even if they do, having something in a certain place on a request type doesn't mean it needs to be front and center on a issue type screen.
• Having empty fields in the same location as when they are filled in
• actually respecting the order of the screen configuration

I'll look at scheduling a call with you to discuss in more detail!

[Flavio Di Transo]

My suggestions:

• add the possibility to move or remove some unwanted default field like "Issue linking" from the bottom of description section
• give the possibility to change the sections layout (like in confluence page)
• give the possibility to arrange the add-ons panels in the description section

[Nicolas LAISNEY]

Hi,

I am not really convinced with the ability for each user to customize its own view. In a team, having the same configuration helps discussion (and in companies where documentation exists, screenshots shall preferably reflect the screens...).

From my point of view, one of the key issues with the issue view is that some fields can not be disabled or layed out (grouped, ordered...) according to our needs. This issue also goes with the overall JIRA side bar, where it is not possible to have control over all items (I would like to hide Goals, some plugins...). Some just cannot be controlled.

[Benjamin Lentz]

Hey,

i want to underline especially the first part of the comment. Standards are helpful and needed for us, every user configuring their own view would be a support and learn problem. 

So if you plan to introduce this, please use team-managed projects for it or give us the possibilty to deactivate it globally / on project level.

The possibility of grouping different fields via scheme would be interesting as well.

Thanks for your ongoing improvement of jira and the possibilities.

Best regards,

Benjamin

[Anne Saunders]

I agree with not allowing all users to customize their views - there are custom fields we use for reporting and display on cross-functional teams' boards and dashboards that we need people to complete. 

It might be cool to attach views to project roles or groups. My executives have different needs than the project managers or devs (and we're a small shop, so they do get in there some!) and the PMs would probably prefer different fields be given priority. 

[Dave Meredith]

I like the idea of being able to arrange / view / hide according to individual user preference.

However I'd like to make sure there is some form of 'Reset to default view' functionality.

I create standardized Request Forms (In a request type this is the Customer portal view), Forms, View Screens with tabs and Request Type layouts that group relevant information based on the type of work to try and make the UX intuitive for the user. If users can pin, move, hide fields that are needed for the workflow, supporting them is going to be very difficult to even find that field on the screen.

<starting to ramble from my initial point>

Side Note: I like having standard layouts for Request Types but if I need to add a field to one Request Type, I then need to add it to 49 other similar request types because there is no shared templates for Request Type layouts which is not a good use of my time...

Also, any field that gets placed on the Request Form (Customer portal view) gets moved from where I placed it in an Agent View Screen or Request Type layout. Putting that field in a Form instead stops this behaviour but you don't always want to attach a form.

Then there's the differences between UX and functionality in the agent transition screens...

Thinking it through the UX of Customer / Agent views seems VERY disjointed and difficult to create a standard experience.

</ramble>

[Ben Ernest-Jones]

There are already several tickets entered for Jira Cloud about reducing white space between fields... that alone would help quite a bit to see more at once without scrolling.

Also what would help with that is to allow at least 2 columns of fields on the main page at the top when viewing an issue. That's generally a lot of wasted space that could be better used so that you can see more information vertically.

[Rune Rasmussen]

Agreed.
It often feels like Jira is built for a low resolution 4:3 monitor.

[Rune Rasmussen]

Firstly, I think this could be a neat addition. There is something similar already in Software Projects.
I expect this would apply to all projects no matter the type.
Would it also be possible to export/import these customizations, or share them between users?
This could greatly save time in cases where multiple teams work in the same Project, by giving each team their own "baseline" of what's shown and what's hidden.

But I ultimately don't think this will resolve the problem you are trying to address.

The thing that has caused a significant amount of clutter for us is that when a field is added to a screen, it is also added to the layout of any Issue (or request) type that uses the screen.
Doing something about this behaviour would (from our point of view) do much more to resolve the problem of clutter with too many fields.

If I were the king and queen of all cheese, I would want both.
The new feature proposed, and for fields to not automatically be added to the Issue/Request layout when they are added to a screen.

I wanted to book a feedback session, but the hours seems to range from 00:00 to 07:30 CET, which is when I get my beauty sleep.

[François Dumas]

I also would really like to book a feedback session as I have many ideas and opinions on the subject but no slots are suitable for my timezone. Any possibility to arrange a slot outside of what is available in Calendly? (I did that a few months ago with another product manager regarding Issue List view 😉)

[Ashley]

Awesome! 

Listing out some things I'd love to see:

• being able to change the description of a field based on issue type within a project (will be useful for unifying/consolidating projects and having useful/valuable helper text)
• masking field names on issue view as you can also mask the name on the customer portal (will be useful for custom field management)
• may be beyond scope but masking status names on issue view as you can also mask the name on the customer portal

[Mathew Lederman]

While I appreciate the desire to improve the Issue View for all projects, I think you need to fix what is broken today with issue views. JSM projects do not have access to the Issue Layout and don't respect the configuration of the View screen (tabs, field order, etc).

For my enterprise service desk with 1000 agents that all share a single sub-task issue type, this means 1 giant list of fields in the Context pane that usually only show when data is populated, and about 5 fields in the Description pane that are only applicable to 1 team but cannot be hidden when empty.

Please fix broken items before looking to implement new changes.

[Symantha Gates]

Some kind of dynamic schema for JIRA admins would be useful so they could "skin" the issues - for their tenancy and their projects.

JIRA does not provide information about default and custom fields - this would be super useful to users and to admins (https://community.atlassian.com/t5/Jira-Cloud-Admins-questions/Project-admins-How-do-you-find-all-fields-used-in-your-team/qaq-p/2738812).

If there were a metadata schema screen available to JIRA admins, we could have a base + variable configuration. For example, JIRA admins select a collection of fields as the base configuration for all issues and then each project adds a collection of other fields to allow customization of the project's fields. 

[Leonard Hussey]

Things I'd like to see:

1. per-user field space selections: Default, Cozy, Compact -- there is a lot of free space between one field and the next. Some screens feel like we need to scroll forever. Especially on information-dense projects

2. inherit some of Confluence's visual options:

- layout: be able to split a section in two or three columns with embed-able contents

- expand: be able to embed jira fields into a section that can be collapsed and allow it to be set with a default status: collapsed or expanded

- tables: be able to embed jira fields into a sort of table-like layout.

I have a very specific need for the last one. I have 5 stages in my ticket flow, each stage has 6 fields for different pieces of data of the stage. This is 30 fields one below the other. Info is needed by service managers to have a clear view of the ticket progress. Arranging these in a table-like structure (which allows columns and row headers) would be great. Sort of like below:

Stage   | Header_1  | Header_2  | Header_3  | Header_4  | Header_5  | Header_6
-------------------------------------------------------------------------------
Stage 1 | Field_1_1 | Field_1_2 | Field_1_3 | Field_1_4 | Field_1_5 | Field_1_6
....
Stage 5 | Field_5_1 | Field_5_2 | Field_5_3 | Field_5_4 | Field_5_5 | Field_5_6

above, "field_x_y" means to show the actual value of the field. This would achieve better visualization and data condensation.

[Symantha Gates]

Agree, this would be super useful. JIRA is really good at pulling us right down into the weeds of the story.task to support developers. This type of thing would help the dev/eng manager, the scrum master, the product owner who are looking at work more cross functionally and across more than one project.