KunjanSharma / gwt-chronoscope

Automatically exported from code.google.com/p/gwt-chronoscope
GNU Lesser General Public License v2.1
0 stars 0 forks source link

Auto zoom feature suggestion #152

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Three improvement suggestions for the auto-zoom feature:

1. Support auto-zoom by multiple datasets. (currently one has to choose the 
dataset according to which auto-zoom will be performed)

2. Don't auto-zoom while dragging. Dragging temporarily reduces resolution, and 
can thus flatten peaks in the data. This causes the range to change and the 
graph to "jump" up and down.

3. Animation. Suppose you have a relatively flat line, with one huge peek. 
Scrolling the peek area out of the viewport will cause a very significant 
zoom-in, throwing the user into disorientation. Smoothly zooming in or out 
allows the user to retain the logical context.

Original issue reported on code.google.com by tom...@gmail.com on 29 Oct 2010 at 9:03

GoogleCodeExporter commented 9 years ago
I thought (1) did work, so that might be a regression.  Totally valid on (2).  
Have you experimented or do you have a suggestion on the tween times that work 
for (3) ?

Original comment by timepedia@gmail.com on 6 Nov 2010 at 8:34

GoogleCodeExporter commented 9 years ago
I was wrong about (1) - it work well.

I haven't tried to implemented (3), so no insight there. I could live with the 
normal tween times, I guess.

I would like add two more suggestions:

4. Round up the last tick value. Users seems to object to seeming numbers like 
39.78465 on the axis.

5. This might not be auto-zoom specific, but auto-zoom emphasizes the need for 
it:
add an option to define top and bottom "padding" so that the data won't reach 
the edges of the plot area. When, for example, I have a dataset with an 
interval of some constant value, it will merge with the X axis and will look 
like a "hole" in the data.

Original comment by tom...@gmail.com on 7 Nov 2010 at 5:17