I agree, the more I think about it the more I like it too. I’m thinking a full revolution = 60 minutes by default.
Feel free to code it or send me the algorithm. But I have a feeling I’ve seen the algorithm/code on stackoverflow before.
And yes, you’re right, I’ll have to modify my swipe code to use the start of the swipe to distinguish between horizontal, vertical and dial. I’m thinking dial should be triggered on a 45 degree angle??
LOL.
Thanks bro! 
I’m thinking of dial primarly being used in verry small circles, but that it could also be used in big cirkles, and more importantly, that the trigger seamlessly blends in with the other swipe actions.
I think that it should be possible to go between current swipe behavior and dials back and forth without the need of lifting the finger. Yes it’s more work, but I think it will be worth it to get it right.
Having a deciding move in the beginning of the swipe “locking down” the mode for swipe until finger lifted is perhaps easier and faster to implement, but also a potential source of frustration when triggered by accident, and then the behavior is not as expected.
Seamlessly blends in the actions could be done for example by the trigger being if the line crosses itself, and if the area inside it is “round enough”, so that it’s not triggered by accident when swiping back and forth and making a verry flat shape.
Sure, perhaps for small cirkles= with area less than say 1/4 of the viable map, and if bigger it could be 24 h per revolution.
A tricky part here is to deside how and when to change the meaning of a full revolution.
More thinking is needed. 
This would be nice but it might have some unwanted artifacts. For example, the blend function might mistake a dial action for a horizontal swipe, in which case the time will go forward or back by a big amount. This would mean what you’re wanting fine detail for would vanish.
But it did make me realize something. To detect a the type of swipe, I would let the user swipe a bit, and then determine what type of swipe it is. But this means there will be a annoying lack of action for a little bit.
Alternatively, we can assume any swipe action starts as a dial and if after a little bit it doesn’t look like a dial, it’ll change to either horizontal or vertical.
I’m not sure blending would be a good idea but we can try it at a later date - after we get the basic dial function going. Same with the variable dial size.
What I’ll do is create the dial and then add a temporary setting to change behaviour. I think our first goal is to get a dial or 45 degree swipe going so we can test them.
If you’re moving forward, I would suggest you get any kind of swipe to work over the whole app: graphs, scale bars, lower icons, but specifically over “time text”. (It works over all the other text but time.)
Things to consider: some like 3+ graphs, which makes graphs a larger swiping area than the map. Also, with multiple graphs and holding a phone left-handed, a dial swipe is likely to start in “time text”. The current behavior would be buggy.
I know you can make it better because my favorite swipes are off map: #1 off map swipe is to swipe from “temp text” right (until I get to the day I’m interested in) #2 is to down swipe into the “scale bar/lower icons” then swipe right (without lifting the thumb) to view the map and the graph “day highlight” change as I swipe. (This method gets my distracting thumb out view) #3 I’ll up swipe into the graph then right swipe (this hides the data behind my thumb, focusing my attention on the scroll of graph data under the “vertical bar” with the map largely in view)
These off map swipes would be intuited if they could be initiated off map to begin with.
I wonder what large arching swipes will be like in Flowx!?
Yes I’ve been thinking about this verry ting for the past days.
Getting something new started for testing purposes is always a good thing. A “quick and dirty” solution for testing, then refinement based on the outcome of the tests.
I’m quite sure that what we want, in order to keep the users happy, is that a potential blend funktion, is not breaking the current behavior of horisontal and vertical swipe, and one that does not require one to lift the finger between the different actions. And it need to be cheap on the cpu. (I’ve been thinking in terms of integrals, but am trying to simplify the math for the computation further.)
I do think that the current behavior of the diagonal swipes can be altered since they don’t really mean anything useful at the moment.
More thinking is required…
What if you could single tap day of week to jump to that day?
A single tap “on graph” is needed. It’s intuitively called for! But, I’m unsettled on how intelligently a single tap “on graph” should be. (It’s such an inaccurate gesture, given it’s a thumb on a phone.)
I welcome it to just move (snap) the vertical bar to a new location (in time) but figure it should account for thumb inaccuracies by: snapping to the same time of day it “snapped from” or snap to a set time of day (noon maybe). The coolest thing a “graph tap” could do is jump to the high point (value) nearest the tap.
Of course, since @duane is willing to take such good care of us all, I should just go ahead and ask for a little haptic thumb massage as I tippity-tap on graph.
Maybe then, I’ll start using my toes with Flowx… for the toe massage. Thanks in advance @duane !!
+1 on this one.
That’s what I was saying & meaning/implying
We used to have tap-on-graph to go to the time many years ago. I hardly used it. When I rewrote the app, I didn’t add it and no one complained. So I’m not convinced it’s needed.
I think there are a few reasons it’s wasn’t used so much:
I must emphasis, it is really important we keep Flowx simple.
I have learnt that although you think it’s obvious, not all users will see it as obvious.
I heard a story once of the Palm pilot employee who sole job was to count clicks. The less clicks the easier. I can’t find the story online but here is a link alluding to it. Read the “Zen of Palm” part.
