Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Screens, One screen for creation, edit, and view or multiple screens for each?

Aaron Geister
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 11, 2020

How do you create your screens for issues? Do you like to have them as one screen for each purpose of creation, edit, and view, or do you like to have a separate screen for creation and edit/view?

 

I really interested to see what everyone is doing. I have read the documentation on how to but it really up to the admins and users to configure these how they want. There is I know a best practice but I am interested in every ones thoughts on this. 

4 comments

Dave Liao
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 11, 2020

Best practice is to have one screen for each, and customize lightly and logically:

  • On the Create Issue screen, just put the absolute needed fields.
  • On the Edit Issue screen, add supplementary fields.
  • The View Issue screen, can pretty much equal the Edit Issue screen, as only filled-in fields will appear when viewing an issue.

On the Edit and View Issue screens, consider tabs to group related-fields. If your Create Issue screen has relatively few fields, you can skip tabs to streamline issue entry.

Hope this helps!

Like # people like this
Aaron Geister
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 11, 2020

Thanks for the feed back. I am self taught and ran into some issue with screens as I been using one screen to define it all. I am working toward my admin certs and want to start to use a better practice so we can make fields appear after words like during the view and or edit. I will be doing lots of copying here soon to get these screens adjusted. 

 

When I first started I remember someone saying at least a creation and edit. Than he didn't use view or something like that. I would think view would show all detail that needs to be seen on the ticket as it is in a close state for all notes?

Dave Liao
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 12, 2020

Generally Edit and View screens can have the same fields (as Nic recommends), except @Dirk Ronsmans mentions a good case for storing read-only/dynamic custom fields on the View screen.

Nic's right - whether you use a single or multiple screens depends on your situation. I prefer individual screens to make edits later (if you choose to do so) easier. But it IS a preference, and not a best practice... 😉

Like Aaron Geister likes this
Dirk Ronsmans
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 12, 2020

U can always start with the same screen for edit/view and if needed duplicate it and change it then :)

That's how I usually work! (only make an extra one if needed :))

Like # people like this
Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 11, 2020

Oh, multiple screens, in most cases.

But.  Always do the requirement analysis.  There is no "best practice" though, you should always work to do the "good practice that works best for your people in the environment you all work in".

My guidelines:

  • Create screen should ask for all the information the reporter is likely to have or feel useful.  Give them all the fields THEY think might be important, but avoid anything that isn't directly relevant.  Only make the absolute minimum mandatory.
  • Edit and View screens should show everything.  Be open and honest and share all the information.
  • Transition screens should only show fields that you want input from people when they use the transition

(Exception - don't put some automated/scripted/calculated fields on view.  I often add scripted fields that do things like "show number of attachments", "show number of sub-tasks", and so-on.  People don't need them in issue view, only search and reporting)

Like # people like this
Aaron Geister
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 11, 2020

Thanks for the feed back. It is appreciated. I will start to view towards some big changes then.

Dirk Ronsmans
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 12, 2020

I agree with all the previous answers but would like to leave u with one exception.

Yes, normally u would work with 2 screens 

  1. Create: minimal, no overhead and clear
  2. view/edit: as JIRA hides what is empty you avoid clutter anyway and what is viewable could be editable.

But, for some projects I tend to split up the edit and view screen.

Why? Well a very simple reason and a shortcoming in JIRA. If you want to create a read-only field you don't have any way of doing this out of the box except for a small trick where you show it on the "view" screen but don't add it on the "Edit" screen. This stops it being editable from the view screen directly or the Edit screen and in essence has a read-only field.

Only draw-back here is that is is still editable through a bulk action.

Add-ons exist to fix this (such as behaviours) but if you don't have those, this is a little trick. (and afaik, Cloud does not have behaviours either)

Like # people like this
Dave Liao
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 12, 2020

Good call on the read-only fields Dirk!

Like Dirk Ronsmans likes this
Aaron Geister
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 12, 2020

Thanks for the response and head up. I do understand the concepts and when I first started on this I started from the ground up no prior knowledge and made lots of mistakes and some those mistakes I continued to replicate. I then found out it was not so much a mistake as probably not great practice as I lose control with I don't have the separation of screens stated in this discussion. 

I really do appreciate all the feedback. It will make me a better admin and also help me with my certs and understandings. 

Like Dave Liao likes this
Juan Felipe Cardona
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 28, 2022

Another use case is when you have "old fields" that you don't need to use anymore, but you need to keep as visible for old issues.

The new issues don't use those "old fields", so you don't add them to the create and edit screens.

The view screen still has the "old fields", just to be seen if you look for an old issue.

Like Dave Liao likes this

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events