[PATCH] Highlight New Events in Timeline

[Mikael Relbe]

This is a suggestion to slightly change the presentation of new events on the Timeline. A patch is attached that implements the following.

New events since the Timeline was viewed last time are highlighted:

Pressing the Update button, revisiting or reloading the Timeline, will make the highlighting go away for the currently viewed events.

No highlighting is made when the Timeline is viewed for the first time!

This behaviour does not interfere with the case when a precise event on the Timeline is browsed, which is the case when a time stamp link directs a user to a precise event on the Timeline.

In case there are unread events on the Timeline, and a user is directed to it via a time stamp link, highlighting of the precise event takes precedence:

Implementation notes

Database usage: The datetime of the latest (topmost) event, presented on the Timeline, is stored in the session_attribute table, with name timeline.lastread on datetime.isoformat.

(I didn't grasp how the date formatters in datefmt.py can be used with microseconds resolution. Using the inbuilt datetime.isoformat() should be fine, I hope you agree on this.)

[Mikael Relbe]

Patchfile for Trac 0.12dev-r9588

[Mikael Relbe]

This is my first contribution to the actual code of Trac, be nice ;)

[Christian Boos]

The patch is fine (ok, we could have stored the lastread as a timestamp, and do a comparison on the timestamp, but using a string compare on the isodate as you did should also work in all cases).

However I'm vary about the excessive visual impact this has (IMO).

We could eventually have a green side bar on the left "a la Visual Studio", that would be more discreet and still very informative.

[Christian Boos]

Illustration of the effect of the corresponding patch

[Christian Boos]

highlight the unread events by using a green sidebar (applies on top of attachment:t9282_timeline-highlight-new-events-r9588.patch​)

[Christian Boos]

#9282: use microsecond timestamps for storing and comparing lastread (applies on previous patch)

[Mikael Relbe]

Really nice changes!

Based on previous patches, I have made a slight modification to the use case:

When the Timeline is updated while any filter setting is changed by the user, the selection of "new events" is not affected.

Say, for example, that Timeline is currently configured to exclude ticket changes. Open the Timeline, which will not show ticket changes, of course, but other events along with a green bar indicating the new ones. Enable ticket changes and press Update to find out if any new ticket changes also happened since last time the Timeline was viewed.

[Mikael Relbe]

#9282: indication unchanged when filter updated, and minor changes to css. (Applies to previous patch.)

[Mikael Relbe]

I really like the visual impression that Christian suggested in comment:4, and I'm all for it. I changed the css slightly since the numbers didn't add up regarding widths, and I also thought that the green bar could be somewhat thicker (which is a matter of taste and experience) so I changed that just for consideration.

I will happily compile a cumulative patch, if that's desired.

[Christian Boos]

Replying to mrelbe:

… I changed the css slightly since the numbers didn't add up regarding widths,

… which was done on purpose, as otherwise, as strange as it seems, you end up with a misalignment. The default 1em margin corresponds to 13px, and the split in .55em, .2em, .35em correspond to 7px, 4px and 2px, at least in the default font size for Firefox, Chrome and IE8. Rounding issues I suppose.

But OK, I'll also try your solution.

[Mikael Relbe]

Replying to cboos:

… which was done on purpose /…/ you end up with a misalignment.

Ehum, I noticed that my proposal causes misalignment on my screen as well… sorry.

Rounding issues I suppose.

Indeed, two decimals seems to be needed.

But OK, I'll also try your solution.

Thanks, but please focus on the behaviour (change filter, update) and not the misaligned bars. (However, the widths 0.38em/0.31em/0.31em looks nice I think, please try that instead.)

I saw that milestone:next-major-0.1X was set. What are the requirements to make this go into 0.12.1? (No criticism, I am just curious about how planning works here on t.e.o.)

[Mikael Relbe]

#9282 — replaces all former patches, works with Trac 0.12b1 (r9596)

[Mikael Relbe]

If this is good enough, perhaps it can be addressed for 0.12.1?

[Remy Blank]

Replying to mrelbe:

I saw that milestone:next-major-0.1X was set. What are the requirements to make this go into 0.12.1? (No criticism, I am just curious about how planning works here on t.e.o.)

We're still working on that (re-defining our development process, the milestones and re-assigning tickets). The milestone descriptions should be edited shortly to reflect the result, and should explain what goes where and why.

[Mikael Relbe]

Re-scheduling according to new planning strategy as outlined in ​trac-dev:5956.

[Mikael Relbe]

#9282: example of indication of new events

[Mikael Relbe]

#9282: example of indication of both new events and precise event

[Mikael Relbe]

#9282 — replaces all former patches, works with Trac 0.12b1 (r9615)

[Mikael Relbe]

The patch t9282_timeline-highlight-new-events-r9615.patch​ replaces all former patches and can be applies on 0.12b1 or trunk r9615. Differences since last patch is improved logic and bug fixes.

Use case slightly changed (we're getting there…). Indication of new events are kept when the timeline is revisited by either pressing the Update button or any of Previous/Next Period links. This means that you can travel back and forth between periods, and change any setting without having the indication of new events resetted. That happens next time you visit the timeline via the navigation bar.

Design note: To accomplish this, the web form cannot be not used to remember "lastvisit" time since that is not part of a request for Previous/Next period, instead another session key has to be stored: "timeline.nextlastvisit". The logic is anyhow much clearer now.

This is what it looks like:

and with together with an indication of a specific event:

I think this is pretty much done now, what do you think?

[lkraav <leho@…>]

g'd day gentlemen. i think this is a worthy patch, thanks mrelbe. i'm just now in another rss vs e-mail, web-based vs fat client situation, where it is necessary to find an optimal way to use Trac's Timeline in the browser. this patch is definitely an improvement.

my suggestion concerns getting the knowledge that something has been updated and i think twitter-style strategy would be quite functional here. when you leave twitter in a background tab, it will keep polling it's timeline and display "unread" event count in tab title:

Twitter / lkraav (5)

tab title will be reset when you enter the tab. could this become part of this patch?

[Mikael Relbe]

You mean that the label in the navigation bar should be dynamically updated, like

Timeline (5)

and then after some time

Timeline (8)

without actually updating the web page?

Interesting idea, but I think this conflicts to current design principles, we have to ask the core team of Trac.

I think that this function, if decided to go into trunk, should be a minimal change as it is now, and then perhaps be enhanced further on, coordinated by a separate ticket.

[Remy Blank]

I think Leho wanted the (x) in the page title, so that it appears in the tab label. Instead of refreshing the whole page, we could probably do this with an XMLHttpRequest, and insert new entries into the existing page.

[lkraav <leho@…>]

rblank is correct.

[Christian Boos]

My take is that the extra enhancements ideas from Leho should go in a separate ticket (preferably created once there's a proof of concept patch). Note that I suspect it will be quite cumbersome to duplicate the logic in the timeline template in javascript, unless the updates are restricted to stay in the same day.

I didn't had the time to test t9282_timeline-highlight-new-events-r9615.patch​, but note that the link in the Timeline tab can eventually be modified to contain parameters, so the reset check won't work in all setups (see TracNavigation).

Even without this, I don't see yet the benefit to have a persistent notion of new events, as opposed to the simpler and IMO more intuitive behavior of the original patch. But I probably have to test this myself to really see the benefit ;-)

For the layout, OTOH, comment:14 is perfect for me.

[Mikael Relbe]

Replying to cboos:

My take is that the extra enhancements ideas from Leho should go in a separate ticket (preferably created once there's a proof of concept patch). Note that I suspect it will be quite cumbersome to duplicate the logic in the timeline template in javascript, unless the updates are restricted to stay in the same day.

Agree, and I don't think I am suited for this.

I didn't had the time to test t9282_timeline-highlight-new-events-r9615.patch​, but note that the link in the Timeline tab can eventually be modified to contain parameters, so the reset check won't work in all setups (see TracNavigation).

I am aware of this, but I think it would be most intuitive to do the reset upon visiting the timeline via the main nav bar.

Even without this, I don't see yet the benefit to have a persistent notion of new events, as opposed to the simpler and IMO more intuitive behavior of the original patch. But I probably have to test this myself to really see the benefit ;-)

It's easy to change the logic and try out this to get a feel for this.

For the layout, OTOH, comment:14 is perfect for me.

It should be, you designed it ;)

[Mikael Relbe]

The patch may need some polishing to behave well for RSS feed requests, see #9321 and r9693.

[Mikael Relbe]

Replying to mrelbe:

The patch may need some polishing to behave well for RSS feed requests, see #9321 and r9693.

Existing patch can safely be merged with r9693 (or the other way around perhaps).

[Christian Boos]

I refreshed the patch (t9282_timeline-highlight-new-events-10132.patch​), seems ready to go.

[Christian Boos]

Timeline: highlight yet unseen events with a green sidebar on the left.

[Christian Boos]

Applied in r10140. Thanks Mikael!

And now, what about #2469 and #9220? :-)

[lkraav <leho@…>]

would it be possible for someone to post a screenshot here of the final implementation result?

[Christian Boos]

No need for a screenshot, just see it in action here ;-)

However… this morning I show it to my favorite usability beta-tester, and the outcome was mixed. In particular, the "green" color was associated with some kind of "success" status, and in general it was not immediately clear what was the meaning of that left bar.

When I explained the purpose, the answer was "why don't you show those in bold, like in e-mail readers?". Well, nice suggestion but as such this would go in the way of #2469.

So, what about indeed displaying the dt.unseen in bold (not the whole entry, just the dt) and find another distinctive way to mark what is "owned", something less intrusive than bold and that we could reuse elsewhere (like a shade of orange or another color) whenever the there's a match the current user. So we could use it on the ticket page itself (#ticket border), in comments (#changelog h3 border-bottom), or in the history listings. We should also use it for the user name (underlining? background?) in the "logged in as user" message on the top, and perhaps also for the Preferences navigation link, so that the association between the color and the user can't be missed (hopefully ;-) ).

[Mikael Relbe]

I think your beta-tester is right. Let's re-open this and produce an alternative according to your thoughts. I have not started working on #2469 yet ;-)

[Mikael Relbe]

Timeline: highlight yet unseen events as bold text

[Mikael Relbe]

Try bold text instead of the green sidebar.
This patch is certainly not one of the heaviest around here ;)

[Christian Boos]

In the meantime I grew fond of the green bar ;-) What about having both?

Have a try on the demo-0.13/timeline which demonstrates this.

Feedback from others?

[Mikael Relbe]

See comment:37:ticket:6492 for a proposal, combined with other features, that results in the loss of the green bar, which I also got fond of ;)

[Christian Boos]

Replying to mrelbe:

… that results in the loss of the green bar, which I also got fond of ;)

No! … Well, it's been a while now we got used to the green bar, and I think we all like it the way it is!

I think we can safely ignore my comment:27 (well the part about "my stuff" in a special color is still worthwhile, IMO), and close the ticket again. Great job, Mikael!