Page MenuHomePhabricator

Allow users to customise data granularity for edits over time graph
Closed, ResolvedPublic

Description

On the statistics page (e.g. https://hashtags.wmflabs.org/graph/?query=test), we hard-coded the data buckets for the edits over time graph see (https://github.com/WikipediaLibrary/hashtags/blob/master/hashtagsv2/graphs/views.py#L57). If the search results data spans less than 90 days, we break it down by day; if between 90 days and 3 years we break it down by month; and for more than 3 years we break it down per-year. This might be frustrating for users who want per-month data for 3.5 years worth of data, or per-day data for 100 days worth of data, for example.

Instead of hard-coding this data granularity, we should provide users with the option to switch between per-day/month/year buckets on this graph.

  • Add radial buttons or a drop-down for Daily/Monthly/Yearly next to the 'Edits over time' graph
  • Use the existing logic to determine the default option
  • If users click a different time option, change the displayed data to correspond to that data granularity
  • Also modify the CSV download for this graph to correspond to this granularity so that data download matches the visible graph
  • Add any relevant tests

Event Timeline

Samwalton9-WMF triaged this task as Medium priority.

@Samwalton9 So for example if a hashtag with result data span for say 2 years is viewed in daily mode, then will not it become messy. Like

Screenshot from 2020-01-25 14-38-35.png (781×1 px, 70 KB)
.

Or as an alternate if a user chooses daily for a hashtag with result span over 90 days , then it will display result from just the last 90 days.

For a span of 2 years, user really would not want to view the daily edits but for a span of 100 days they might want to. Therefore, we will provide them the option for customisation but after that it's their choice. When user lands on the statistics page for the first time, the default behaviour should be from hardcoded rules only as it is now but after that, they will have the option to customise. Let's see what @Samwalton9 have to say on this. :)

I agree with Aditya - I think it's best to just provide the user with the choice in all cases rather than try to make guesses about what will or won't look good. Just provide all options all the time :)