"Update New Ticket" UI should fit on one screen

[lashchev@…]

Since Trac is (successfully) pitching a minimalistic approach to task/bug management - UI should be as simple as possible so it takes seconds for users to update tickets/tasks.

To achieve this:

• Current ticket properties panel should be hidden by default (if not completely removed) since:
  • Read-only fields (opened on.., last modified) are shown in title only
  • UI shows all ticket properties at the bottom of the page where you can change the values. Showing current values twice has no use and takes a lot of screen space.
  • If there is a need to review changes in the ticket - same approach as in Trac Wiki should be used where options are: Review Changes/Preview/Submit
• Comments:
  • Should have 3 display forms:
    • Collapse all (default)
    • Expand all
    • Expand some (when you click on a title of a particular comment)
  • "Collapsed" form of a comment should display comment text in a brief form by default (one-liner by default). May be number of chars or lines to display should be configurable (like in search results)
  • "Expand" form should look like it is right now
• Attachments:
  • Section should be collapsable (collapsed by default)
  • Section title should include number of current attachments (like "Attachments: 5")
• Style, status (hidden/visible), location on the page and order of displayed properties should be consistent with "Create New Ticket" page

[osimons]

See also #7639, #7641.

[mikec@…]

Several things are unclear about this ticket. First, is "Update New Ticket" the correct name for the page being discussed? I'm assuming we're talking about what is seen when you view a ticket.

What is the use case where you want to have it "take seconds to update"? What exactly are you updating so often that compressing the display to highlight your preferred fields is worth the reduction in information? I personally am not finding the current display to be at all onerous, but I do see some opportunity for streamlining.

"Fit on one screen" is a very nebulous metric that fails to take into account a huge variety of browser-window sizes.

• Ticket property display
  • The Ticket Properties are important; I don't see why you want to hide them. While hiding some may make updating a ticket faster for some tasks, it will slow down others. If a particular field isn't suitable for your application, then making it removable in the configuration is fine; but if it's been decided that it's a necessary field,
  • Don't forget that the UI for the ticket properties at the bottom of the page only shows up for users with appropriate privs. I agree that the redundancy is undesirable. However, text display is easier to read than fields, and more compact.
    Displaying text for the fields, with a little 'edit' link adjacent that, when clicked, replaces the text with editable fields (similar to what Bugzilla has been doing lately) would be an approach worth considering.
• I could be sold on the idea of All Collapsed being the default, but I think better would be tracking which comments have been seen and expanding new ones. (Which probably should be a new ticket.)
• The biggest issue with the Attachments panel is all the space taken up by the panel when there are no attachments. Changing to float the Attach button to the right of the section title and hiding the pane would definitely be an improvement.
• I agree that the order of displayed properties should match that of the New Ticket form; that was an early source of confusion when I started with Trac.

[Andy]

My requirement is exactly the same. I'm interested to see this feature soon. Request someone to complete it. Interested in knowing the milestone and the owner.

[Remy Blank]

Replying to Andy:

My requirement is exactly the same. I'm interested to see this feature soon. Request someone to complete it. Interested in knowing the milestone and the owner.

The owner could be you, and in that case, the milestone could be pretty soon ;-)

[ebray]

I agree with mikec's comments. This doesn't seem necessary it all. I don't see how not fitting all of a ticket's properties on one "screen" is a usability issue. Not to mention, I have some Trac instances that have almost nothing but custom fields, and the obvious implementation of your suggestion would require users to expand the ticket properties section every time they modify a ticket.

For the default fields, I can see a case for trying to make them "positioned" the same on both the new ticket and update ticket pages. But also keep in mind that plugins can completely nullify this—we use plugins that change the fields in a ticket depending on its stage in a workflow.

I think if you really needed something like this it could be accomplished with a simple plugin to add some JavaScript.

[Remy Blank]

Replying to ebray:

For the default fields, I can see a case for trying to make them "positioned" the same on both the new ticket and update ticket pages.

Hey, that's been implemented in [7564] ;-)

[Christian Boos]

See also #8295, where we're heading to minimize the screen space in preview mode.

One note about the "Collapse all (default)" suggestion and the other suggestions in description to collapse as much things as possible: I think doing this will just achieve the opposite effect, as people will want to look anyway into these sections for not risking to miss something important. So I'm quite sure the "collapse all" approach will slow things down as you'll click through all the expandable sections first. By contrast, showing all the information makes it easier to grasp at a glance what's important or not, and then you could still collapse some sections in a second step if it makes the ticket more compact. In preview mode, it makes sense to collapse what's not directly related to the edit being made, as you can assume the user has already had an overview of the whole ticket before reaching the preview.

[Remy Blank]

Some of the items in this ticket have been addressed in #8295, and I'm not sure what remains to be done to close this ticket. Maybe the reporter could test the current trunk and let us know what he thinks?

[Vladimir Lashchev <lashchev@…>]

Replying to rblank:

Some of the items in this ticket have been addressed in #8295, and I'm not sure what remains to be done to close this ticket. Maybe the reporter could test the current trunk and let us know what he thinks?

Is there any system which is built against trunk daily and where I can access? I do not have any test systems handy anymore - all of them have a lot of customizations and are actively used by other developers.

[Remy Blank]

Replying to Vladimir Lashchev <lashchev@…>:

Is there any system which is built against trunk daily and where I can access?

Not that I know of, but IIRC Christian was suggesting we do exactly that for our own testing, so this might happen at some point.

[Christian Boos]

Watch #4163 ;-)

[Christian Boos]

Milestone 2.0 deleted

[Remy Blank]

Still waiting for feedback to comment:10.

[sue.sml2006@…]

I was not the original reporter, but I can say that being able to set the "order" property of built in fields would be very useful, which was a feature request in the original enhancement request and why I happened upon this record.

[Christian Boos]

Replying to sue.sml2006@…:

I was not the original reporter, but I can say that being able to set the "order" property of built in fields would be very useful,

Setting the order "globally for standard and custom fields would indeed be nice (improve ticket customizations - see #9648).

Otherwise, I'd say the many changes we did in 0.12 for #8295 achieve the goals stated in this ticket, closing as duplicate.