Last modified: 2014-08-05 08:22:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T70470, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 68470 - Story: EEVSUser selects time range
Story: EEVSUser selects time range
Status: NEW
Product: Analytics
Classification: Unclassified
Visualization (Other open bugs)
unspecified
All All
: Normal enhancement
: ---
Assigned To: Nobody - You can work on this!
u=EEVSUser c=EEVS p=34
:
Depends on:
Blocks: 68350
  Show dependency treegraph
 
Reported: 2014-07-23 20:42 UTC by Kevin Leduc
Modified: 2014-08-05 08:22 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kevin Leduc 2014-07-23 20:42:45 UTC
as an analyst, I can set the start & end dates to visualize, so I focus the visualization on a narrow period of time.
Comment 1 Kevin Leduc 2014-07-29 20:48:32 UTC
Team discussion on points:
Filtering may happen at client
Can be a naive filtering. Performance is secondary. If the performance is bad, we can add another card to improve performance.
We need to implement a custom control for time selection

NOTE: the high point value is mostly due to the fact that we're implementing a new custom time selection control.
  Changing what is possible to select would not make the filtering easier, but choosing a simple (calendar-only for example) control would simplify things. 
  Filtering by itself, with an out of the box calendar-only time selection would cost: 13 points
Comment 2 nuria 2014-08-05 08:22:27 UTC
> Performance is secondary. 
>If the performance is bad, we can add another card to improve performance.
Sorry, but if filtering is done client side (the only way it can be done giving our current access to data) performance cannot be bad. We are just repainting as all data is already loaded into memory. If performance is bad on that scenario indicates a problem with painting, problem that we would have in the vanilla use case of painting data not filtered.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links