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

[Aaron Geister]

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. 

[Dave Liao]

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!

[Aaron Geister]

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]

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... 😉

[Dirk Ronsmans]

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 :))

[Nic Brough -Adaptavist-]

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)

[Aaron Geister]

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

[Dirk Ronsmans]

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)

[Dave Liao]

Good call on the read-only fields Dirk!

[Aaron Geister]

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. 

[Juan Felipe Cardona]

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.