rfe: collapsed ticket description modification window

[hamish_b@…]

Hi,

I am a co-admin for a project using trac. As it happens I'm also a busy developer for the project and so spend a lot of time commenting on bug reports etc.

When logged in in admin mode a "bug description" text box opens between the new comment text box and the Preview button, which lets you change the initial report text.

It would really be great if that text box could by default be collapsed in some [+] [-] way so that it is not so easy to accidentally type into or delete content from the wrong box as you go back and forth between the Preview button and the comment box! I only really feel that it is valid to edit the initial report if some sort of privacy breach has occurred there so usually would like it to be hidden somewhere out of harms way.

thanks, Hamish

[Remy Blank]

How about having a second set of "Preview", "Submit changes" buttons placed between the comment box and the "Change Properties" box?

[Christian Boos]

Replying to rblank:

How about having a second set of "Preview", "Submit changes" buttons placed between the comment box and the "Change Properties" box?

Yes, and I think there something to do here in connection with #454. I should look at that patch once more before merging it, but I remember there was also a couple of preview / save buttons below the textarea for the comment edit. I think it would be nice to have the same buttons with the same styling also below the normal Comment text area, at the place you suggested.

Also, this suggestion for an additional preview/submit made me think it would really be cool to have a submit just below the preview, so that when you're satisfied with the preview, you don't have to click skip and scroll down even more to reach the Submit button. Though the need for this additional scrolling would go away with the suggested change, I still think it would be nice to be able to validate a preview in a more straightforward way.

[Christian Boos]

Replying to hamish_b@…:

It would really be great if that text box could by default be collapsed in some [+] [-]

I'm sure there was already such a request (I even made a patch for it IIRC), but I'm unable to find it now.

See also related discussion in #7639 and #7640.

[hamish_b@…]

Replying to rblank:

How about having a second set of "Preview", "Submit changes" buttons placed between the comment box and the "Change Properties" box?

that would certainly help, although from a design standpoint I'd consider it a slightly redundant solution which doesn't really address the underlying problem. My main concern and the reason I filed this wish isn't really the extra effort it takes to scroll up and down the page (although that is a pain), it is the danger of accidentally modifying the ticket's original description.

say there's a live wire between you and the door you use to get in and out everyday. Is the better solution to add another door to the room, or to insulate the wire?

also I worry if there are 2 submit buttons it might be confusing to newcomers as to if by pushing it you will just be updating the comments, the properties, or both.

just my 2c, Hamish

[Remy Blank]

Replying to hamish_b@…:

that would certainly help, although from a design standpoint I'd consider it a slightly redundant solution which doesn't really address the underlying problem.

I did understand your initial issue, but you have to keep in mind that your use case is not necessarily the most common use case. Myself, I wouldn't want the ticket property fields be hidden by default, because I change them often. Sure, we could add a configuration option, or even a user preference to configure that, but this in turn increases the complexity of the configuration.

As cboos mentioned above, we think there is a benefit to adding the buttons close to the comment field, and maybe even next to the preview, but we're not sure that hiding the property editor is a good idea.

Now, for your use case, I would suggest you try to implement this as a plugin. It could be done quite easily, in fact. You have to implement IRequestFilter, have it add the JavaScript file js/folding.js when rendering the ticket.html template, and add a little JavaScript snippet to toggle the collapsed class of the #properties fieldset. Look at the query.html template for an example how to do that.

[Christian Boos]

I'm sure there was already such a request (I even made a patch for it IIRC), but I'm unable to find it now.

That was #7062, now closed as duplicate of this one.

[Christian Boos]

The notes I was writing in reply to comment:169:ticket:454 were more fitting here:

1. Wouldn't that prevent modifying the description at the same time as ticket fields? If yes, then I think I prefer the current state.

So what about this:

• by default, the ticket description textarea is not shown (#8295), and we have an Edit inline button in the description
• after clicking this Edit button, this time we'll show ticket description textarea, "as usual"

2. That sounds like a very good idea. I am always annoyed to have to click "skip" to go down from the preview to the editable fields. So except for point 1, I'd like to try that.

But if the ticket description is modified as well, we would have to scroll up to see the description preview, then down again. Not good either.

Maybe in this case (and in this case only) we could place the description preview above the description textarea?

This would give the following layout:

Ticket #xxx
+---------------+
|  preview for  |
| ticket fields |
|               |
| Description:  |
|  (see below)  |
+---------------+
> Attachments
 .
 .

> Change History
 .
 .
 .
 .
 .
 .

+-------------+
|   comment   |
|   preview   |
+-------------+
+-------------+
|   comment   |
|   field     |
+-------------+
-- Change Properties -
Summary: ___
Reporter: ___
Description: 
 +-------------+
 | description |
 |   preview   |
 +-------------+
 +-------------+
 | description |
 +-------------+
-- Action -
 .
 .
|Preview| |Submit|

The description preview would be shown only once in the document, and in the upper box there would be a (see below) link leading to the description preview at the bottom of the page.

After a Preview, we would be placed at the level of the comment preview, so we should still see the comment preview and the description preview (as for 0.11) but nevertheless be close to the rest of the form, so limiting the up/down scrolling.

When the ticket description is not modified, then it can be displayed as usual after the preview of ticket fields.

[Remy Blank]

I have been experimenting with this, and it should also solve #8608. But I need to work on it some more.

[Christian Boos]

A complementary idea: in preview mode, fold the Attachments and Change History, so that only the form fields and their preview are visible. The full information is still there if needed, but doesn't take any screen space by default.

[Remy Blank]

Nice idea! However, I am trying to avoid <fieldset>, as that's what triggers #8608. Do you mind if I use a "(show)" link next to "Attachments" and "Change History" for unfolding?

[Christian Boos]

I don't like so much text links that are actually actions (that's why we have e.g. the "Reply" as inlinebutton and not as a text link).

I don't think we necessarily need to have fieldsets for collapsible sections, we could add another mechanism, like:

<h2 class="collapsed" id="collapse_changelog">Change History</h2>
<div id="changelog">
  <div class="change">...</div>
  <div class="change">...</div>
  <div class="change">...</div>
  <div class="change">...</div>
</div>

and add a clicked() callback on h2.collapsed/expanded to show()/hide() the xyz element corresponding to the collapse_xyz id.

[Remy Blank]

I agree that actions are normally represented by buttons, but make the title a trigger for collapsing? At least a link gives you an indication that it can be clicked. Or did you mean to decorate the title with the same triangle that we normally use on <fieldset>?

[Christian Boos]

Replying to rblank:

…. did you mean to decorate the title with the same triangle that we normally use on <fieldset>?

Indeed, sorry for being unclear about that.

[Remy Blank]

Improved ticket editing

[Remy Blank]

The patch above takes most of the ideas described here, and improves ticket editing by hiding non-essential information at various stages in the edit (and contrary to what I stated in comment:5, I now prefer having the ticket property form hidden by default). Most sections (attachments, changes, properties, actions) are now collapsible. I won't describe everything in detail and just let the changes speak for themselves.

It also makes the attachment lists on wiki pages and milestones collapsible. This might come in handy when printing a page with lots of attachments.

One thing that is still missing: the ticket description editor is still in the property fieldset. If we move it below the actual description (in the same way as the comment editor), we won't be able to change both the description and other fields at the same time. I find this acceptable, but I would like to have your opinion.

Anyway, I'm quite pleased with the result :-) Thoughts?

[Christian Boos]

Very nice, but nevertheless I have a couple of suggestions for further improvements…

Concerning the attachment sections:

• on the wiki view, the default should be collapsed I think; on a wiki page you're mainly interested into seeing the attachments displayed in context within the page itself, whether they are inlined images or referenced documents; the attachment summary list is secondary.
• on the ticket view, the default to expanded is correct, as for a ticket one need to see at the first glance if there are attached documents or patches

Also, I don't like so much the heterogeneity of the folds:

• Attachments and Change History are "section" folds,
• then we have the Add a comment section which is not a fold,
• finally we have Change properties and Action which are "fieldset" folds

What about replacing the last two by an unique Modify Ticket section fold containing both (non-foldable) fieldsets?

The detail of the Add a comment section could also be simplified. Instead of:

• Add a comment
• Author fieldset
• Comment (toolbar)
• textarea

We could have:

• Add a comment
• (toolbar)
• textarea

And the Author fieldset could be moved to the bottom of the page, just above the Preview and Submit buttons. Visually that should fit well with the Change properties and Action fieldsets when the Modify Ticket section is expanded. Also, having it close to the buttons makes it the last thing you see before submitting, a nice reminder for filling them…

The preview mode is indeed working better when we collapse the attachments and ticket history, and I'm pleased to see #8608 fixed ;-) The only things I'm not completely happy with are the (top) and (edit) links for moving around. I don't really have an alternative to propose, but at least I think those text links should better be replaced by up and down arrow icons.

I believe these additional changes will make the presentation of the ticket page even nicer. Now let's verify this theory ;-)

[Christian Boos]

Implements suggestions from comment:15, applies on top of 8295-new-ticket-edit-r8750.patch​.

[Christian Boos]

Replace (edit) and (top) links with skip icons. Applies on top of 8295-presentation-tweaks.patch​.

[Remy Blank]

All the changes from the first patch are excellent. I like the consistency of the whole page, it makes good use of the available space, and putting the author at the bottom should indeed motivate people not to post anonymously. Very nice!

The second patch I don't like at all. The arrows look out of place, and their purpose is not immediately apparent. I like the idea of using arrows, though. How about the following patch, which also collapses milestone attachments by default.

[Remy Blank]

Better in-ticket navigation links. Applies on top of 8295-presentation-tweaks.patch​.

[Christian Boos]

I'm glad you liked the bulk of the changes ;-) We have indeed something very cool now.

8295-nav-links.patch​ is fine by me, except we could do:

trac/ticket/templates/ticket.html

@@ -103 +103 @@
                   has_property_editor = not version and version != 0 and not cnum_edit
                                         and (can_append or can_modify or can_edit or can_create)">
       <div class="trac-nav" py:if="(ticket.exists or preview_mode) and has_property_editor">
-        <a href="#propertyform" title="Go to the ticket editor">modify &darr;</a>
+        <a href="#propertyform" title="Go to the ticket editor">modify</a> &darr;
       </div>
       <h1 id="trac-ticket-title" py:choose="">
         <py:when test="ticket.exists">
@@ -287 +287 @@
         <div py:if="ticket.exists and can_append" class="field"
             py:with="show_comment_preview = change_preview and cnum_edit is None">
           <div class="trac-nav">
-            <a href="#content" title="Go to the top of the ticket">top &uarr;</a>
+            <a href="#content" title="Go to the top of the ticket">top</a> &uarr;
           </div>
           <h2 id="trac-add-comment">
             <a id="edit" onfocus="$('#comment').get(0).focus()">Add a comment</a>

for consistency with what we do in the contextual navigation. By the way, the modify link is close to the contextual nav, so we have a kind of funny "compass rose" effect there ;-)

I also wonder if those links are necessary at all… We're doing nothing more than offering shortcuts to go either to the top or to the bottom of the page, something that can be achieved with the keyboard or gestures…

Before committing the changes, maybe it would be worth doing 2 commits for each of the patches (8295-new-ticket-edit-r8750.patch and 8295-presentation-tweaks.patch): one doing the actual modifications without reindenting, followed by a reindenting changeset without any other modifications.

[Remy Blank]

Replying to cboos:

8295-nav-links.patch​ is fine by me, except we could do:

Yes, that looks even better.

I also wonder if those links are necessary at all… We're doing nothing more than offering shortcuts to go either to the top or to the bottom of the page, something that can be achieved with the keyboard or gestures…

I am using the "Skip" link very often (on 0.11) after a preview, as it jumps exactly to the location I want to continue working. Now that we change the preview to show the bottom of the ticket, I find it convenient to be able to jump to the top to see the ticket preview, and back to the fields, with a single click. Sure, the Home and End keys do almost the same, but my hand is usually on the mouse at that time, as I just clicked on "Preview".

In short: I find them useful.

Before committing the changes, maybe it would be worth doing 2 commits for each of the patches (8295-new-ticket-edit-r8750.patch and 8295-presentation-tweaks.patch): one doing the actual modifications without reindenting, followed by a reindenting changeset without any other modifications.

Funny you mention that. When I started working on this ticket, I did minimize the diffs by avoiding re-indentation. Then at some point I was convinced enough that the result was good, so I fixed all the indentation ;-)

I'll try to separate the indentation, but I'll have to do it by hand.

[Remy Blank]

I have committed the full functionality in [8753] with minimal whitespace changes and fixed the indentation in [8754].

[Christian Boos]

Replying to rblank:

The second patch I don't like at all. The arrows look out of place, and their purpose is not immediately apparent. I like the idea of using arrows, though. How about the following patch, which also collapses milestone attachments by default.

I have a new version of these navigation links, which are now made similar to the ones that I introduced for the wiki editor in #8721. Therefore the ticket8295-nav-reworked-t8721.patch​ is on top of ticket:8721:ticket8721-enhanced-wiki-editor-r8872.patch​.

(sorry for the many whitespace changes, I used emacs which cleaned up the trailing spaces)

[Christian Boos]

Tweaks the intra-page navigation links, made them similar to the ones for the wiki editor in #8721.

[Remy Blank]

Can't say I like them, sorry… I find the arrows themselves pretty ugly, and having them next to a title that doesn't say where they lead is confusing. For example, the arrow next to "Add a comment" leads to the "Submit" button, and the arrow next to "Submit" leads to the top of the page.

[Christian Boos]

Ok, I understand your objections, but I also stand by my point: the current presentation of the intra-page links as of r8754 is not good either, the page is really too cluttered with links that way…

[Remy Blank]

Replying to cboos:

Ok, I understand your objections, but I also stand by my point: the current presentation of the intra-page links as of r8754 is not good either, the page is really too cluttered with links that way…

Yes, let's say it's the least ugly I could find so far. Give me a bit of time to make another proposal.

[Christian Boos]

Replying to rblank:

Give me a bit of time to make another proposal.

In the meantime, please have a look at ticket:8721#comment:13 (sorry for the back-and-forth between the two tickets, but this really crosses both of them).

[Remy Blank]

Add an "Attach file" button at the bottom of the ticket page.

[Remy Blank]

The ticket page is now nice and clean. One usability issue persists, though. When I'm reading the last comments on a ticket, and I want to attach a file, I have to scroll up to the list of attachments.

The patch above adds an additional "Attach file" button next to "Preview" and "Submit changes" to make scrolling unnecessary.

Thoughts?

[Christian Boos]

As all the buttons at the bottom deal with the changes done in the ticket fields and the added comment, I'm not sure it will be easy to guess what pressing on an "Attach file" button there will do… save the changes and proceed to file attach? Discard the changes?

Maybe showing the "I have files to attach" checkbox also in edit mode could do the trick? Or another intra-page navigation link. Either would be preferable to an Attach button, I think.

[Remy Blank]

I'm not a huge fan of the intra-page navigation link, and it requires two clicks instead of one to go to the "add attachment" page, but I agree that the button requires some guessing and is therefore not ideal, and I don't have anything better to suggest (the "I have files to attach" checkbox is not intuitive).

So let's go with the navigation link. Something like "Attachments"?

[Remy Blank]

Committed in [8912].

[hamish_b@…]

cheers,

Hamish

(overenthusiastic spam filter means I have to write more)

[Ryan J Ollos <ryano@…>]

Replying to rblank:

So let's go with the navigation link. Something like "Attachments"?

I think this turned out well. I find the Attachments link to be pretty intuitive since it has an up-arrow next to it.

Replying to cboos:

• on the ticket view, the default to expanded is correct, as for a ticket one need to see at the first glance if there are attached documents or patches

My preference would be to have the Attachments section collapsed by default and for the section title to indicate the number of attachments. For this ticket, Attachments (6) would be displayed. Perhaps the Attachments link could also cause the Attachments box to be expanded when jumping to it.

My argument for this feature is that most users only care about comments, and collapsing the attachments section makes the page seem much less busy.

I was thinking of opening a ticket to request this feature, but I thought I'd post here first for comment since it is related to this ticket and was briefly discussed. I searched for Attachments collapse, but surprisingly didn't find any discussion about this.

[Ryan J Ollos <ryano@…>]

Replying to Ryan J Ollos <ryano@…>:

My preference would be to have the Attachments section collapsed by default and for the section title to indicate the number of attachments. For this ticket, Attachments (6) would be displayed. Perhaps the Attachments link could also cause the Attachments box to be expanded when jumping to it.

One wrinkle to this that I realized after posting my comments is that if the Attachments section was made collapsed by default then the Attach file button should probably be brought out of the collapsible section.

[Remy Blank]

Since the small revolt in #9807, I don't dare hiding any sections by default anymore ;)

[Ryan J Ollos <ryano@…>]

Replying to rblank:

Since the small revolt in #9807, I don't dare hiding any sections by default anymore ;)

Haha, I understand. Perhaps a plugin for configuring the default state of each ticket section is in order, as you suggested early in this ticket.

[Ryan J Ollos <ryano@…>]

Replying to rblank:

Since the small revolt in #9807, I don't dare hiding any sections by default anymore ;)

Since the attachments on a wiki page are hidden in the collapsed section when the page is loaded, do you think it would be useful to show the number of attachments in the way that I suggested earlier for the ticket page, i.e. Attachments (6)? Without this, there is no immediate way to see that the page has attachments?. Maybe it is not all that useful to know that a page has attachments … I think that I tend to prefer that it is possible to see at a glance.

[Remy Blank]

Replying to Ryan J Ollos <ryano@…>:

do you think it would be useful to show the number of attachments in the way that I suggested earlier for the ticket page, i.e. Attachments (6)?

Yes, that would be a nice addition.

[mmihajlovic@…]

How about making the parameters of the ticket (Reported by, priority, components) a collapsible section as well? I know with me, the most important part I need to see is the description - everything else makes it more difficult for me to read the problem and fix it…

[Remy Blank]

Please don't re-open old tickets marked as "fixed" for new enhancement requests. Instead, file a separate enhancement request. Thanks.