Edgewall Software
Modify

Opened 10 years ago

Closed 9 years ago

#9282 closed enhancement (fixed)

[PATCH] Highlight New Events in Timeline

Reported by: Mikael Relbe Owned by: Mikael Relbe
Priority: highest Milestone: 1.0
Component: timeline Version: 0.12dev
Severity: minor Keywords: lastvisit
Cc: leho@…, ryano@… Branch:
Release Notes:

Highlight timeline events which are new since last visit

API Changes:

Description

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

Attachments (13)

screencapture1.gif (14.8 KB ) - added by Mikael Relbe 10 years ago.
screencapture2.gif (7.4 KB ) - added by Mikael Relbe 10 years ago.
t9282_timeline-highlight-new-events-r9588.patch (2.8 KB ) - added by Mikael Relbe 10 years ago.
Patchfile for Trac 0.12dev-r9588
t9282-timeline-sidebar-for-new-events.png (13.3 KB ) - added by Christian Boos 10 years ago.
Illustration of the effect of the corresponding patch
t9282-timeline-sidebar-for-new-events.patch (2.4 KB ) - added by Christian Boos 10 years ago.
highlight the unread events by using a green sidebar (applies on top of attachment:t9282_timeline-highlight-new-events-r9588.patch)
t9282-timeline-lastread-in-microseconds.patch (2.8 KB ) - added by Christian Boos 10 years ago.
#9282: use microsecond timestamps for storing and comparing lastread (applies on previous patch)
t9282-indication-unchanged-when-filter-updated.patch (2.1 KB ) - added by Mikael Relbe 10 years ago.
#9282: indication unchanged when filter updated, and minor changes to css. (Applies to previous patch.)
t9282_timeline-highlight-new-events-r9596.patch (5.4 KB ) - added by Mikael Relbe 10 years ago.
#9282 — replaces all former patches, works with Trac 0.12b1 (r9596)
t9282-timeline-sidebar-for-new-events-2a.gif (9.2 KB ) - added by Mikael Relbe 10 years ago.
#9282: example of indication of new events
t9282-timeline-sidebar-for-new-events-2b.gif (10.1 KB ) - added by Mikael Relbe 10 years ago.
#9282: example of indication of both new events and precise event
t9282_timeline-highlight-new-events-r9615.patch (3.9 KB ) - added by Mikael Relbe 10 years ago.
#9282 — replaces all former patches, works with Trac 0.12b1 (r9615)
t9282_timeline-highlight-new-events-10132.patch (4.3 KB ) - added by Christian Boos 9 years ago.
Timeline: highlight yet unseen events with a green sidebar on the left.
t9282_unread-timeline-bold-items-r10150.patch (805 bytes ) - added by Mikael Relbe 9 years ago.
Timeline: highlight yet unseen events as bold text

Download all attachments as: .zip

Change History (45)

by Mikael Relbe, 10 years ago

Attachment: screencapture1.gif added

by Mikael Relbe, 10 years ago

Attachment: screencapture2.gif added

by Mikael Relbe, 10 years ago

Patchfile for Trac 0.12dev-r9588

comment:1 by Mikael Relbe, 10 years ago

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

comment:2 by Mikael Relbe, 10 years ago

Summary: [PATCH] Highlight Unread Events in Timeline[PATCH] Highlight New Events in Timeline

comment:3 by lkraav <leho@…>, 10 years ago

Cc: leho@… added

comment:4 by Christian Boos, 10 years ago

Milestone: next-major-0.1X

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.

by Christian Boos, 10 years ago

Illustration of the effect of the corresponding patch

by Christian Boos, 10 years ago

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

by Christian Boos, 10 years ago

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

comment:5 by Mikael Relbe, 10 years ago

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.

Last edited 10 years ago by Mikael Relbe (previous) (diff)

by Mikael Relbe, 10 years ago

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

comment:6 by Mikael Relbe, 10 years ago

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.

in reply to:  6 ; comment:7 by Christian Boos, 10 years ago

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.

in reply to:  7 ; comment:8 by Mikael Relbe, 10 years ago

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

by Mikael Relbe, 10 years ago

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

comment:9 by Mikael Relbe, 10 years ago

Owner: set to Mikael Relbe

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

Last edited 10 years ago by Mikael Relbe (previous) (diff)

in reply to:  8 comment:10 by Remy Blank, 10 years ago

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.

comment:11 by Ryan Ollos <ryano@…>, 10 years ago

Cc: ryano@… added

comment:12 by Mikael Relbe, 10 years ago

Milestone: next-major-0.1X0.13
Priority: normalhighest
Severity: normaltrivial

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

comment:13 by Mikael Relbe, 10 years ago

Status: newassigned

by Mikael Relbe, 10 years ago

#9282: example of indication of new events

by Mikael Relbe, 10 years ago

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

by Mikael Relbe, 10 years ago

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

comment:14 by Mikael Relbe, 10 years ago

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:

#9282: example of indication of new events

and with together with an indication of a specific event:

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

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

comment:15 by lkraav <leho@…>, 10 years ago

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?

comment:16 by Mikael Relbe, 10 years ago

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.

comment:17 by Remy Blank, 10 years ago

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.

comment:18 by lkraav <leho@…>, 10 years ago

rblank is correct.

comment:19 by Christian Boos, 10 years ago

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.

Last edited 9 years ago by Christian Boos (previous) (diff)

in reply to:  19 comment:20 by Mikael Relbe, 10 years ago

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

Last edited 9 years ago by Christian Boos (previous) (diff)

comment:21 by Mikael Relbe, 10 years ago

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

in reply to:  21 comment:22 by Mikael Relbe, 10 years ago

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

comment:23 by Christian Boos, 9 years ago

Keywords: lastvisit added
Release Notes: modified (diff)

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

by Christian Boos, 9 years ago

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

comment:24 by Christian Boos, 9 years ago

Resolution: fixed
Status: assignedclosed

Applied in r10140. Thanks Mikael!

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

comment:25 by Christian Boos, 9 years ago

Severity: trivialminor

comment:26 by lkraav <leho@…>, 9 years ago

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

comment:27 by Christian Boos, 9 years ago

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 ;-) ).

comment:28 by Mikael Relbe, 9 years ago

Resolution: fixed
Status: closedreopened

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

by Mikael Relbe, 9 years ago

Timeline: highlight yet unseen events as bold text

comment:29 by Mikael Relbe, 9 years ago

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

comment:30 by Christian Boos, 9 years ago

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?

comment:31 by Mikael Relbe, 9 years ago

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

in reply to:  31 comment:32 by Christian Boos, 9 years ago

Resolution: fixed
Status: reopenedclosed

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!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Mikael Relbe.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Mikael Relbe to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.