(Thread got umbaringly long, and after a pushed update I think v2 was in order.)
Some of my notes:
Single tap to set time, should not be activated allreddy on the “button down”-event / at “touch start” but at the “button up”-event / at “touch end” and only if the time between them are under half a second or so. Otherwise it is accidentally triggered when it is unwanted, for example at start of a scroll or a side swipe.
Bug: the time-line is not set for the graphs that are not in view when scrolling. (See screen shot below.)
The time-line is, in my opinion to hard to see, (especially when outside) so a sugestion is to make it a bit higher contrast and or thicker, and/or to make it continous, meaning aslo drawn on the gray areas between the graphs.
Instead of displaying the text “Monkeys wedding” or equivalent at the top of the screen, please display the name of the location displayed. I that is more useful. (Or display both, if it fits).
Bug, (only reproduced sometimes) when changing location, then opening compare, then taping back button (the left arrow at top left corner) it did (sometimes) not only take me back to the map but also changed location to one earlier displayed.
@Ohan I noticed that I just thought it was since the graphs not in view the line does not move figured it was a coding thing in view it moves not in view it doesn’t since you can’t see it tell you scroll.
This was a hard one because we use double-tap which meant there was a delay before a single tap is registered. It seemed laggy.
The alternative is to use swipe to set time, just like on the map, and remove the single tap. Personally, I don’t really like it. Maybe we should try this.
Will fix.
You’ll have to wait for the theme editor to set it yourself. If I change it, someone else will complain that it’s too think. I will not win this battle.
I (did initially) agree with this! Remove the single tap, use swipe only.(Or don’t!) (See alternatie
in new post below)!
And if possible make swipe and scroll abel to register input at the same time. Meaning a diagonal swipe will move the time-line while scrolling.
(I’m fed up with a beaveour in a completely different app, that locks one of the directions at the time, and if trying to scroll it refuses if there is the slightest side direktion in the swipe. So annoying.)
@Ohan I’m confused why slide time line while scrolling does that not defeat the purpose of comparing? That’s why I liked the single tap in compare mode. I understand everyone likes different things.
Since the line can be hard to see sometimes, it helps allot to wiggle it a little bit, so the eyes can easely find it on the screen. Detecting motion is somethings that our eyes and brains are good at.
This is something that I think would be helpful allso while scrolling, but more importantly:
When checking the forecast for two different times I would, while I keep my finger down on the screen, scroll, wiggle, swipe to second time, wiggle, swipe back to first time, scroll to see the other data sourses, wiggle, swipe to second time, wiggle, swipe back to first time.
So being able to seamlessly, without lifting finger from screen to put it back down, perform swipe and scroll, is for this reason important.
To be forced to do a release with finger off screen between every action would potentially cause much frustration, (as is does in the other app i described).
Sugeation for keeping single tap for setting time:
(I went creative to display indentation in this pseudo code.)
start “code”
Have 2 timers.
At “button down for touch” start a timer (reset the one with biggest value, making it the timer with the smaller value).
. At “button up for touch”;
. _ if timer (with smallest value) is less than 0.5 s;
. _ _ then perform “set time”;
. _ else
. _ _ # don’t perform “set time”, just continue with swipe and/or scroll.
. _ _ if timer (with smallest value) is more than 0.9 s;
. _ _ _ then perform “long-press”;
. _ _ endif
. _ endif
. _ if timer (with bigger value) is less than 1.2 s;
. _ _ then perform “double tap”;
. _ endif.
end “code”
This way a dubbeltap action will always include one (and potentially two) singl tap action(s).
There is no need to wait for finding out if a dubble tap happened before performing a single tap.
This should take care of removing the risk of it seaming laggy.
In compare mode, it makes totally sense to replace single tap with swipe, but I feel that I actually still can argue for putting back the “single tap on graph to set the time” in the map-mode (normal view), since there one can already swipe on the map.
(Or make swipe over the graphs work also in the map-view, but in this case I would like the single tap back.)
@Ohan in compare mode when you scroll to the desired time then double tap the graph you want when it returns to map view the time you selected is displayed on the map
Ahhhh, is this why this was happening. I didn’t figure out why. I’ll work on improving the swipe/scroll. But I think the proof-of-concept is right. It’s just the polish that remains.
I don’t agree for a few reasons:
it replicates a existing function, i.e., it’s redundant.
it’s different from the compare-mode, i.e, users will single-tap in compare-mode and find it doesn’t work. This will frustrate them and raise complaints.
gestures are rare and should be saved for more valuable feature we might come up with in the future.
Also, let’s just see how this goes instead of rushing into more changes. After a few weeks or months, it’ll be obvious if we should add it or not. It has to be obvious, not on-the-fence.
