Closed brendano closed 8 years ago
hrm. that is weird. i have noticed other annoying things like that. I had to write a lot of logic to try and distinguish between click, drag bar, drag rectangle etc. I will take a look and debug.
as long as we're wishlisting on the slider -- i think when it's in unselected mode, the initial mouse action should be to drag out an initial selection. like a rectangle selection tool in any drawing program. right now, when you mousedown, it causes a fixed width selection to appear around where the mousedown happened.
that would make sense if the interpretation is a desire to look at a single point in time. but i dont think that's the right interp of a mousedown. it is, though, the correct interp of a click, by which i mean, the mousedown and mouseup both occur without any mouse movement (or perhaps, the horizontal mouse movement is less than the size of the most granular x-axis unit). i do not know to what extent the dom/react notion of a click matches that. my guess is they demand zero tolerance for movement (which is a fine first approximation or perhaps the most desirable approach)
@brendano I added in "i think when it's in unselected mode, the initial mouse action should be to drag out an initial selection. like a rectangle selection tool in any drawing program. right now, when you mousedown, it causes a fixed width selection to appear around where the mousedown happened". It is definitely better. Thanks.
I think the mouse behavior should be: -if no grey rectangle yet, then mousedown starts an initial drag out (this is what it does now) -if rectangle: a short click (mouse down/up w/in 250 ms) moves the rectangle to the click location w/o changing the width of the rectangle -if rectangle: a long click starts a new drag out from mouse location, undoing the current rectangle
cool. one thing right now:
i think the rectangle shouldnt change its width?
ya. i agree width should stay the same.
I think I got all of these. It is still really hard to push the slider all the way to the left. I think b/c of a really subtle thing w/ padding? need to look into this.
Also: Should\ be able to drag 2x. Right now: can only drag to start rect, but can't drag to a new spot.
"Also: Should\ be able to drag 2x. Right now: can only drag to start rect, but can't drag to a new spot." => now fixed.
However, there is little delay built in to distinguish bween click/drag. if you drag really quickly you can get halfway across the chart before the UI realizes you intend to drag. if your mouse is down and you cross two bins, needs to toggle drag too.
@brendano do you think a discrete click should move the rectangle? I think we can do away with this so that all mouse downs are drags (1. drag the whole grey rectangle, 2. drag the black bars, 3. drag out a new region of the chart). if the user happened to "drag" quickly (i.e. click) there would just a minimum width constraint for the rectangle so it would be as if they dragged a 1 month span. This would probably be closer to what they intended anyway.
distinguishing between click/drag is a headache + I'm not sure that the click really enhances anything. if anything: it means the user (either consciously or unconsciously) also needs to keep click vs drag straight in their head too. this is a relic from the c3 days + should be cut.
ok 3 minutes later i feel convinced that clicks should be interpreted as mini drags. the user will not care how wide the rectangle was before they clicked. the click is a signal of interest in a particular region.
no i dont think a click should ever move the rectangle. i guess i've been thinking the interaction would be something like this?
Steve Myers smyers@thelensnola.org Special projects editor, The Lens 504-298-9750 @myersnews
On Mar 16, 2016, at 1:08 PM, brendano notifications@github.com wrote:
no i dont think a click should ever move the rectangle. i guess i've been thinking the interaction would be something like this?
click on rectangle: just make it do nothing. only a drag does stuff. click outside of rectangle: kill the selection. or maybe, create a new smallest-granularity-width selection (e.g. one-day width) — You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub
I showed this to my friend Gabe who points out why it should support click.
1) load Rookie. 2) hover over the graph to see a tool tip 3) click for details (this feels totally natural)
UI should open one month wide span along the timespan
Steve Myers smyers@thelensnola.org Special projects editor, The Lens 504-298-9750 @myersnews
On Mar 24, 2016, at 6:16 PM, Abe Handler notifications@github.com wrote:
I showed this to my friend Gabe who points out why it should support click.
1) load Rookie. 2) hover over the graph to see a tool tip 3) click for details (this feels totally natural)
UI should open one month wide span along the timespan
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
ya. as if you were to drag out a 1 month span
Steve Myers smyers@thelensnola.org Special projects editor, The Lens 504-298-9750 @myersnews
On Mar 24, 2016, at 6:19 PM, Abe Handler notifications@github.com wrote:
ya. as if you were to drag out a 1 month span
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
i dont have strong intuitions which is better. i do think the old behavior is bad: if an interval is selected, a click outside the interval moves the entire window. not good. either kill the selection, or create a new minimal-sized selection.
can a mousedown immediately create the minimal-sized selection, so dragging naturally creates a larger interval? i think this is getting too finegrained to discuss in text
hard to explain. see video below. (made with Quicktime Player -> New Screen Recording)
http://hobbes.cs.umass.edu/~brenocon/20160228_slider_wonkiness.mov