ticket type change not shown in preview

[Markus.Staab]

if changing the type of a ticket and press preview button, the change of the property is not indicated in the preview.

[Christian Boos]

Look again.

But well, as it seems we'll never reach consensus about putting the ticket title in the yellow box (#3336), and that it's apparently still too easy to miss the status and type when they're outside the box, even when written in big bold letters, I'll try to put the status and type fields back in the yellow box and see if that makes it easier to not miss them.

[Noah Kantrowitz]

Perhaps the title should got inside the preview box (or be copied inside the box) if either value has changed?

[anonymous]

why don't have a list which show all diffs like it is already shown above a comment which changes a property?

something like

    * type  changed from defect to enhancement
    * milestone set to 0.12

I thought something like this was already implemented in the preview before…? hmm

[Christian Boos]

Replying to anonymous:

… I thought something like this was already implemented in the preview before…? hmm

Oh right, looks like an important regression, sorry for having missed the obvious…

Retargeting to 0.11 (for the field change preview, not for moving the ticket type and status from the title to inside the box).

[Christian Boos]

Replying to cboos:

Replying to anonymous:

… I thought something like this was already implemented in the preview before…? hmm

Oh right, looks like an important regression, sorry for having missed the obvious…

That was actually a regression due to [6919], which was reverted in [7014]. So that specific issue is fixed.

Retargeting to 0.11 (for the field change preview, not for moving the ticket type and status from the title to inside the box).

Re-targeting again to 0.12, for moving the ticket type and status from the title to inside the box.

[Remy Blank]

Replying to cboos:

Re-targeting again to 0.12, for moving the ticket type and status from the title to inside the box.

Is this still desired? FWIW, I like it as it is now.

[Christian Boos]

Replying to rblank:

Replying to cboos:

Re-targeting again to 0.12, for moving the ticket type and status from the title to inside the box.

Is this still desired? FWIW, I like it as it is now.

Yes, I still think the current layout is not optimal. The ticket number, type, status and resolution are all part of the main ticket content, which is this yellow box representing a physical ticket or card.

Another example: if we would use a background for the wiki page (well, in fact like we do in preview mode), you wouldn't want to see the page's main title outside of it either.

Furthermore, I think simply moving the title back in the yellow box wouldn't be enough, as it's still too easy to miss important information. Let's think about some more radical changes. We could add a visual hint about the ticket type, with an icon (say 32x32, a bug or bomb for defect, a light bulb for enhancement), and a visual hint about the status (maybe a color border for new/… etc. and an overlay icon if closed, depending on the status: green check mark for fixed/worksforme, red x for wontfix, invalid).

It would look like this:

 +------------------------------------------------------------+
 | +---+  Ticket #7197  (new enhancement)                     |
 | |(@)|  **ticket type change not shown in preview**         |
 | +---+                                                      |
 | Created 2 years ago              Last modified 4 weeks ago |
 | ___________________________________________________________|
 | Reported by: ...                           Owner:  ...     |
 | ...

(HTML mock-up to come later, once I've found the icons I have in mind ;-) )

[Remy Blank]

Replying to cboos:

Let's think about some more radical changes. We could add a visual hint about the ticket type, with an icon (…)

Yes, why not. That could look quite nice.

(HTML mock-up to come later, once I've found the icons I have in mind ;-) )

Speaking of which, we should provide a number of stock icons, so that even the artistically-challenged like myself can configure their Trac properly ;-)

[Christian Boos]

Looks like I forgot to upload the screenshots I made back then. I found the icons on the web, but they're not reusable, so they're just used here as an example.

[Christian Boos]

Ticket's <h1> placed on the "ticket" itself, with an icon matching its type

[Christian Boos]

Same, with an overlay for the closed status, matching the resolution

[Christian Boos]

Move ticket title in the ticket box, along with a visual representation of the type (still applies on r10060)

[Christian Boos]

Also show the ticket close time, if available. Applies on visual-ticket-type-r9975.patch​.

[Christian Boos]

See also t10012-drop-double-borders-from-ticket-box.jpg.png.jpg:ticket:10012​.

It would look even better if all the information would be in the box.

Actually, I'll try the following:

------------------------------------------------------------------------------
                                             | Wiki | Tickets | Source | ... |
------------------------------------------------------------------------------
ticket:7197                                          <- Prev | Back | Next ->

               .---------------------------------------------.
               | Enhancement #7197       created 2008-05-05  |
               |                         last mod  ...       |
               |  closed: fixed          closed    ...       |
               |                                             |
               | ticket type change not shown in preview     |

[Christian Boos]

how it looks like with [8a50acc4/cboos.git]

[Christian Boos]

Looks like this:

​

The changes already discussed above are:

• [18144368/cboos.git] #7197: move h1 in Yellow Ticket Box™ and restructure it.
• [53abdce2/cboos.git] #7197: add Closed time, if ticket is closed.

Also done while reworking the yellow box:

• [6fff354e/cboos.git] #7197: get rid of the Modify navigation link
• [eacc757d/cboos.git] #7197: dim color for empty fields
• [8a50acc4/cboos.git] #7197: merge Description modified by … with its link to the diff

(pushed on repos:cboos.git:ticket10012/more-good-stuff)

[Christian Boos]

The Attachments section will be improved as part of #10743.

[Remy Blank]

Why make "closed" and "(duplicate)" bold, but not "enhancement"? I would make either all bold, or all normal.

What does the "+#" button do? Is it the replacement for "Modify"? The icon isn't very clear.

Other than that, it looks nice.

[Christian Boos]

Replying to rblank:

Why make "closed" and "(duplicate)" bold, but not "enhancement"? I would make either all bold, or all normal.

To highlight the type. I tried italic, but it doesn't look as nice. If all three were bold, the type wouldn't stand out, and the status pairing (closed/resolution) would be less immediately apparent as well (just look at what we have now, we know it's easy to miss either the type, the status or both).

What does the "+#" button do? Is it the replacement for "Modify"? The icon isn't very clear.

It means "add a new ticket" (i.e. Clone in this particular case). See also #10735.

I think none of the "quick" button is immediately understandable just by looking at the symbol. The thing is that if they're much less used than the corresponding description or comment text is read, so having the full text is starting to be really obtrusive (think [Reply] [Edit] [Delete] [Clone], etc.). If someone wants to operate on a ticket comment (or description here), hovering the mouse on these buttons will give a detailed tooltip, and the association will be quickly remembered if done consistently.

[Remy Blank]

Replying to cboos:

To highlight the type. I tried italic, but it doesn't look as nice. If all three were bold, the type wouldn't stand out, and the status pairing (closed/resolution) would be less immediately apparent as well (just look at what we have now, we know it's easy to miss either the type, the status or both).

I read the type and status as a sentence, not as a list of words, that's why it looks strange to have different "boldness". How about reversing it (making "closed" and "(duplicate)" normal and "enhancement" bold)? Usually you highlight one word in a sentence, not the whole sentence except one word.

I think none of the "quick" button is immediately understandable just by looking at the symbol.

I agree with that, and I have to agree with Leho in #10012 that it's a step back in terms of usability.

(OT: The comment folding seems to mess up links to comments as the one above, at least on FF. When I click the link, I get nowhere near the desired comment.)

The thing is that if they're much less used than the corresponding description or comment text is read, so having the full text is starting to be really obtrusive (think [Reply] [Edit] [Delete] [Clone], etc.).

At least [Reply] is used heavily. The others not so much. Can you at least make it so that the text is still there but hidden (and therefore can be translated), and can be restored with a CSS change only (i.e. not have to write custom Genshi templates)?

[Christian Boos]

Replying to rblank:

Replying to cboos:

To highlight the type. I tried italic, but it doesn't look as nice. If all three were bold, the type wouldn't stand out, and the status pairing (closed/resolution) would be less immediately apparent as well (just look at what we have now, we know it's easy to miss either the type, the status or both).

I read the type and status as a sentence, not as a list of words, that's why it looks strange to have different "boldness". How about reversing it (making "closed" and "(duplicate)" normal and "enhancement" bold)? Usually you highlight one word in a sentence, not the whole sentence except one word.

Yes, that works for me as well, pushed as [b1db78fe/cboos.git].

(OT: The comment folding seems to mess up links to comments as the one above, at least on FF. When I click the link, I get nowhere near the desired comment.)

Works well here in Chrome, and just tried with FF (13.0.1), no problem either. You mean the in reply to: ↑ links?

The thing is that if they're much less used than the corresponding description or comment text is read, so having the full text is starting to be really obtrusive (think [Reply] [Edit] [Delete] [Clone], etc.).

At least [Reply] is used heavily. The others not so much.

Another idea would be to have both "symbol text" (e.g. "(↳ Reply)") and have a "compact interface" preference, in the advanced prefs tab. That could be used to reduce the verbosity in other ways, like removing the Help links.

Can you at least make it so that the text is still there bug hidden (and therefore can be translated), and can be restored with a CSS change only (i.e. not have to write custom Genshi templates)?

Or this, yes.

[Remy Blank]

Replying to cboos:

Works well here in Chrome, and just tried with FF (13.0.1), no problem either. You mean the in reply to: ↑ links?

No, links to comments like comment:75:ticket:10012. But it's not failing consistently, maybe it has to do with how fast the JavaScript executes versus the moment when Firefox scrolls to the anchor. When it fails, I see the page scrolling to the desired location, then a lot of motion on the page (presumably due to JavaScript), and when it stops, the page is not at the right location. If I retry shortly after, it usually works fine.

Another idea would be to have both "symbol text" (e.g. "(↳ Reply)") and have a "compact interface" preference, in the advanced prefs tab. That could be used to reduce the verbosity in other ways, like removing the Help links.

If the symbol was added through CSS, it could also be hidden with CSS if desired, so yes, that's also a good approach.

[Christian Boos]

Will be done.

[Christian Boos]

Fixed as part of r11129.

​Trac 0.8 FTW!

It seems it's no longer possible to find a site running 0.8, the closest thing I found was that screenshot; one day when we're getting really bored (e.g. once Trac 3.0 is done and bug free), we should also extend the collection of /demo- sites downward, back to 0.5 ;-)