Opened 14 years ago
Last modified 13 years ago
#9282 closed enhancement
[PATCH] Highlight New Events in Timeline — at Version 23
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: | |||
Internal 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.)
Change History (35)
by , 14 years ago
Attachment: | screencapture1.gif added |
---|
by , 14 years ago
Attachment: | screencapture2.gif added |
---|
by , 14 years ago
Attachment: | t9282_timeline-highlight-new-events-r9588.patch added |
---|
comment:2 by , 14 years ago
Summary: | [PATCH] Highlight Unread Events in Timeline → [PATCH] Highlight New Events in Timeline |
---|
comment:3 by , 14 years ago
Cc: | added |
---|
comment:4 by , 14 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 , 14 years ago
Attachment: | t9282-timeline-sidebar-for-new-events.png added |
---|
Illustration of the effect of the corresponding patch
by , 14 years ago
Attachment: | t9282-timeline-sidebar-for-new-events.patch added |
---|
highlight the unread events by using a green sidebar (applies on top of attachment:t9282_timeline-highlight-new-events-r9588.patch)
by , 14 years ago
Attachment: | t9282-timeline-lastread-in-microseconds.patch added |
---|
#9282: use microsecond timestamps for storing and comparing lastread (applies on previous patch)
comment:5 by , 14 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.
by , 14 years ago
Attachment: | t9282-indication-unchanged-when-filter-updated.patch added |
---|
#9282: indication unchanged when filter updated, and minor changes to css. (Applies to previous patch.)
follow-up: 7 comment:6 by , 14 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.
follow-up: 8 comment:7 by , 14 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.
follow-up: 10 comment:8 by , 14 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 , 14 years ago
Attachment: | t9282_timeline-highlight-new-events-r9596.patch added |
---|
#9282 — replaces all former patches, works with Trac 0.12b1 (r9596)
comment:9 by , 14 years ago
Owner: | set to |
---|
If this is good enough, perhaps it can be addressed for 0.12.1?
comment:10 by , 14 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 , 14 years ago
Cc: | added |
---|
comment:12 by , 14 years ago
Milestone: | next-major-0.1X → 0.13 |
---|---|
Priority: | normal → highest |
Severity: | normal → trivial |
Re-scheduling according to new planning strategy as outlined in trac-dev:5956.
comment:13 by , 14 years ago
Status: | new → assigned |
---|
by , 14 years ago
Attachment: | t9282-timeline-sidebar-for-new-events-2a.gif added |
---|
#9282: example of indication of new events
by , 14 years ago
Attachment: | t9282-timeline-sidebar-for-new-events-2b.gif added |
---|
#9282: example of indication of both new events and precise event
by , 14 years ago
Attachment: | t9282_timeline-highlight-new-events-r9615.patch added |
---|
#9282 — replaces all former patches, works with Trac 0.12b1 (r9615)
comment:14 by , 14 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:
and with together with an indication of a specific event:
I think this is pretty much done now, what do you think?
comment:15 by , 14 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 , 14 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 , 14 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.
follow-up: 20 comment:19 by , 14 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.
comment:20 by , 14 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 ;)
follow-up: 22 comment:21 by , 14 years ago
comment:22 by , 14 years ago
comment:23 by , 14 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 , 14 years ago
Attachment: | t9282_timeline-highlight-new-events-10132.patch added |
---|
Timeline: highlight yet unseen events with a green sidebar on the left.
Patchfile for Trac 0.12dev-r9588