Add metrics timeline events underneath graphs

added component::metrics/website metrics-timeline owner::metrics-team priority::medium resolution::implemented severity::normal status::closed type::enhancement ux-team labels

Ok here is some feedback from me (isabela). I read the comments from last meeting as well as the Montreal notes and scanned the list discussion :)

Quick thoughts:

yes, the 3rd mock is most readble - but i have to confess that I only understood some of it after reading the columns titles of the mock with the table heh
I also agree on rethinking the copy for this section. My suggestion would be 'Related Events:'
If I understand it right the Events will change depending on my timeframe selection, correct? Are the Events information related to the dots that are displayed when you turn on: "Show possible censorship events if available (BETA):" ? [this will matter for me to understand the experience, that is why I am asking]
I am not sure about using tags that are not clickable (like the protocol and country ones). Yes, we could still classify them and have a way to show that visually. But right now how we are doing gives me the instint of trying to click on it.. or even hoover my mouse to understand better what those are.
I also don't understand the little square before the reference links. Is it to be a horizontal bullet point list? If so, again, I think we can still do that but with some other visual. The square makes me want to 'check' the box hehe
Description of reference links - we should come up with categories or something? and some standard, like always start with capitalized letters.. Have a more consistent presentation.

From your open questions:

Are we going to list all events in the displayed timeframe or just the ones that are related to the displayed country, (pluggable) transport, IP version, or server type (relay or bridge)?

I guess this was my question #3 (closed)

We are adding this list only to the graphs in the Users category, because the metrics timeline focuses on those graphs, too, right?

Suggestion. If this is a new feature just for Users category, I would maybe plan a little banner saying 'check out our new thing' for a week or so, to call attention of people to it.

Should entries be listed in descending order, like on the News page, or in ascending order?

Descending - the newest event closer to the top.

hope this helps. And looking forward to continue the conversation! Antonela will also publish her review comments FYI :)

Thanks for the feedback, Isabela! Some quick responses:

The listed events will not be directly related to the dots from "Show possible censorship events if available (BETA)". Those come from a script, whereas timeline entries are written by dcf and others. It's certainly possible that the two sets overlap, but that's certainly not always the case.
I don't think we can make the tags clickable, because I wouldn't know what to link from them. But we can certainly include a tooltip like "This event is related to the Onion-Routing protocol ()." or "This event is related to users in Turkey." We'd have to find good tooltip texts, though.
The little square in front of links is a missing font issue. Sorry for not making that clearer. It's supposed to be the external link symbol that you find everywhere else on Tor Metrics, including the start page in "... about the [HERE] Tor network?". This already helps a lot. I'm curious to also hear Antonela's thoughts and will then prepare a new mockup. Thanks again!

Replying to karsten:

Thanks for the feedback, Isabela! Some quick responses:

The listed events will not be directly related to the dots from "Show possible censorship events if available (BETA)". Those come from a script, whereas timeline entries are written by dcf and others. It's certainly possible that the two sets overlap, but that's certainly not always the case.

Got it. This should be somehow explained to the user in case the person is looking at the graphic with that on.

I don't think we can make the tags clickable, because I wouldn't know what to link from them. But we can certainly include a tooltip like "This event is related to the Onion-Routing protocol ()." or "This event is related to users in Turkey." We'd have to find good tooltip texts, though.

If they were clickable - my expectation would to be taken to a page with all events related to that tag. Like all events related to Turkey, for that timeframe. like filtering the results.

The little square in front of links is a missing font issue. Sorry for not making that clearer. It's supposed to be the external link symbol that you find everywhere else on Tor Metrics, including the start page in "... about the [HERE] Tor network?".

Aha! :) so that is a tofu! font rendering problem (in the unicode world people call that tofu hehe)

This already helps a lot. I'm curious to also hear Antonela's thoughts and will then prepare a new mockup. Thanks again!

Trac:

hey metrics! Thanks a lot for working on this feature. It is really useful.

I read everything, my 2 cents here:

The 3 columns table is the most readable way to have all this dynamic data imo. What would happen if we use the full weight of it? Mockup attached :) [1]

If the 3rd option is the picked one, I'd like to suggest: - a subtle line to divide rows - maintain the pills [Places/Protocols] at the start of the sentence

+1 with "Related Events" for the title. +1 with descending entries listing - the newest event closer to the top.

I'm also having a strange character on the "link", "ticket" icons. Let me know if you need icons for it, I'll provide.

Also, let me know if you want to discuss anything else about this thread. I think we can add it to our next UX meeting :)

[1] https://trac.torproject.org/projects/tor/attachment/ticket/24260/%2324260-1%20.png

Replying to karsten:

Are we going to list all events in the displayed timeframe or just the ones that are related to the displayed country, (pluggable) transport, IP version, or server type (relay or bridge)?

I was envisioning that we would filter out unrelated timeline entries; i.e., when you're looking at a Turkey graph, don't show Brazil entries. Same with pluggable transports.

However there's still the question of what to do with entries that have a blank "places" or "protocols" cell. I've been thinking of a blank cell as meaning "worldwide" or "all"; e.g. when there's a meek bridge outage I put it in places="" protocols="meek", because there's nothing tying it to a particular country. But if you are looking at a graph for a particular country, should you see those timeline rows? I'm not sure. I thought the logic would be simple but it was more difficult than I anticipated. Currently (Last modified: 2017-11-06) at https://people.torproject.org/~dcf/metrics-country.html I am showing all the blank entries, even when you select a country. For example: if you have selected country=eg, you will get all the entries with "eg" in "places", and all the entries with blank "places", but not any of the entries that are non-blank and do not contain "eg". I'm not sure I like it, though; maybe it would be better to show the blank entries only when you have country=all.

The function accept_entry is what decides which rows to show.

We are adding this list only to the graphs in the Users category, because the metrics timeline focuses on those graphs, too, right?

I think yes, for now at least only in the Users category. There are a few entries, like "deb.torproject.org upgrades from tor 0.2.9 to tor 0.3.0," that affect other category like Servers, but they are not well systematized.

Thanks for all the feedback on this ticket, including a fourth mockup!

I made a fifth mockup and started a list of next steps.

Changes include:

Renamed "Possibly related events" to "Related events".
Extended table width to the space below the graph update form for several reasons:
- There's no point in leaving that space empty.
- With more horizontal space available it makes more sense to use a table with a separate column for tags and save vertical space.
- The table header includes the column headers that isabela was missing.
Changed date column to better distinguish single-day entries from entries starting or ending on a given day:
- Entries without end date to "YYYY-MM-DD and ongoing" (if this sounds like Bad English, let's try to find something else that starts with the YYYY-MM-DD part for better alignment with the other entries).
- Entries without start date to "YYYY-MM-DD and before" (see above; there should not be many of these entries in practice).
Fixed font issue (in all my mockups).
Capitalized first letter of all links.

Immediate next steps are:

Add this table to graphs in the Users category and include all entries except for events related to a different country or transport than the one that is currently displayed.
Adapt the format to the News page.

Next steps after that are:

Add tooltips to tags explaining them a little more, like "Onion-Routing protocol" for "".
Come up with a way to explain that the automatically generated censorship events are unrelated to the manually written events in this table.
Maybe change the filtering to only show entries for all countries or all transports on graphs showing users from all countries or using all transports.
Add annotations to the graph or even mouseovers.
Add optional JavaScript magic that only displays the first entries and that lets the user expend the list if there are more.
Find categories or standards for link texts for a more consistent presentation.
Extend events to graphs in other categories than Users and then add this table there.

How does this sound? Should I move forward with the immediate next steps, and then we improve things from there?

The mockups looks much better now with all that space (I didn't notice that in the first mockup ;-)

Immediate and next steps are fine; except that I would move

Come up with a way to explain that the automatically generated censorship events are unrelated to the manually written events in this table. into the immediate tasks. Maybe place a simple explanation on top or below the table. Later this can be improved, but there should be at least this explanation from the beginning. The question if these two are related is the first question that comes up when noticing the table for the first time. Hence, the answer should be provided immediately.

Sounds good. Want to suggest such an explanation and where exactly to put it? If not, I'll come up with something. (Thanks!)

Well, the sentence of the bullet point is a start:

The automatically generated possible censorship events depicted in the graph are unrelated to the manually written events in this table.

Replying to karsten:

Changed date column to better distinguish single-day entries from entries starting or ending on a given day:

Entries without end date to "YYYY-MM-DD and ongoing" (if this sounds like Bad English, let's try to find something else that starts with the YYYY-MM-DD part for better alignment with the other entries).

Speaking of this, I want to resolve the ambiguity that currently exists between point events (like browser releases) and events that started but haven't finished yet ("ongoing"). Both cases are currently represented in the table as start="something", end="". But that's a topic of another ticket.

I implemented a first version in my task-24260 branch and deployed it on Tor Metrics. (It's just presentation, what could go wrong?)

Please take a look: https://metrics.torproject.org/userstats-relay-country.html

Changes include:

Explained in a short sentence where these events come from.
Added a notice when possible censorship events are shown (and hidden otherwise) saying that events in the table do not necessarily match those in the graph.
Date columns do not include "and ongoing" for events without end date (or "and before" for events without start date), because we'd basically add the "and ongoing" part to every single entry. I agree with dcf that this is something we should resolve in another ticket. For now we're only distinguishing single-day and multi-day events in the table. Should be fine for a start.

Remaining next steps (some as part of this ticket, most as part of new tickets):

Adapt the format to the News page. (Waiting for some initial feedback on the newly deployed table on graph pages first.)
Add tooltips to tags explaining them a little more, like "Onion-Routing protocol" for "".
Make tags clickable by linking them to a page with all events related to that tag. (isabela suggested this above and I forgot to mention it before.)
Maybe make column headers clickable and as a result sort entries accordingly.
Maybe change the filtering to only show entries for all countries or all transports on graphs showing users from all countries or using all transports.
Add annotations to the graph or even mouseovers.
Add optional JavaScript magic that only displays the first entries and that lets the user expend the list if there are more.
Find categories or standards for link texts for a more consistent presentation.
Extend events to graphs in other categories than Users and then add this table there.
Resolve ambiguity that currently exists between point events (like browser releases) and events that started but haven't finished yet ("ongoing"). Both cases are currently represented in the table as start="something", end="".

Trac:
Status: new to needs_review

Replying to dcf:

Replying to karsten:

Changed date column to better distinguish single-day entries from entries starting or ending on a given day:

Entries without end date to "YYYY-MM-DD and ongoing" (if this sounds like Bad English, let's try to find something else that starts with the YYYY-MM-DD part for better alignment with the other entries).

Speaking of this, I want to resolve the ambiguity that currently exists between point events (like browser releases) and events that started but haven't finished yet ("ongoing"). Both cases are currently represented in the table as start="something", end="". But that's a topic of another ticket.

I started #24470 (moved) with some ideas for disambiguation.

Trac:
Keywords: ux-team deleted, ux-team metrics-timeline added

Commit 53978c7 in my task-24260 branch still needs review. It's currently deployed but not merged to master yet. If it looks good (enough), I'll rebase and merge to master. Thanks!

As with #24580 (moved) it might be good to introduce java 8 date time classes throughout the touched/created code, avoiding to use string comparison when actually comparing dates, which could fail when changing date formats. This concerns mostly GraphServlet, MetricsServlet, and News. Should at least be a new (higher prio) ticket.

Sounds good to do this in a new ticket soon.

How's the remaining code? Ready to merge?

As it is running fine it should be merged. All else including tests is for #24635 (moved).

Trac:
Status: needs_review to merge_ready

Great! Cherry-picked and deployed.

Leaving this ticket open until we have either completed some of the next steps suggested above or created tickets for them.

Trac:

Add metrics timeline events underneath graphs

Child items 0

Activity