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.
OK, I can agree with you on the methodology.
I understand your reasons, and partly agree with 2. and 3.
As for 1. I do think it fills a purpose, and for 2. I think that for me (personally) I would be happy with single tap having one meaning when done on a graphs while the map is showing, and another mening while in compare mode, since they are visually quite different modes.
But most importantly, I agree that we should avoid confusing masses of users so that they’ll complain.
(Edit: Yes, “we should avoid… … that they’ll complain”.)
I think you mean “don’t complain” and also allude to the reason for #1. “masses of users” and “confusing”. I try to keep Flowx as simple as possible because with if you confuse 0.1% of 70,000 users, you get 70 support emails or 1-star ratings.
I got a 2-star rating yesterday saying: “Don’t know what the hell it is”.
@FlowxLloyd Hello this is the Complaint Department all our operators are busy at this time please stay on the line and the next available operator will be with you.
@duane pardon my language But DAMN I read the 1 - 3 star reviews people don’t know how to “RTFM” they just download it open it and start spewing crap. 98% of the replies were read the help page. I live in a micro climate big deal I still use the App BECAUSE it shows WHAT MIGHT HAPPEN. it’s people like the giving reviews like those that keep me from learning how to code and create an App I’d get so many 1 star reviews saying “App Creator is an Assh@le with even worse support ethics” I’d be giving out alot of
