Compare Feature v2

not sure it’s a bug but a glitch I could be wrong, I haven’t had it happen.

1 Like

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.

Good idea

Will look into it

2 Likes

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.)

:+1:

OK, yes that’s fair.

:grin:

:+1:

@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.

1 Like

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.

I would like to remove the single tap because of a few reasons:

  1. it doesn’t feel right
  2. it’s too sensitive, e.g. you can easy touch the screen and change something.
  3. it replicates an existing action, swiping.
  4. it uses a gesture for a replicated action. Gestures a valuable.
  5. it adds unnecessary complexity - more help, more user confusions.

It just doesn’t feel right to me. This action seems clunky. I like to keep things simple.

3 Likes

@duane perfectly said to much tapping swiping is smoother and more accurate.

2 Likes

:+1:
I agree with this!

1 Like

I’ve actually just removed single-tap and added swipe, and swipe is much nicer. Should be in beta in the in the next day.

2 Likes

Yes, thank you. Much nicer!

However, if the swipe is not exactly horizontal, it will stop and be interrupted by the scroll, so please,

.

I would be verry happy if to be

:sunglasses:

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

1 Like

@Ohan

I see what you’re saying

1 Like

I didn’t understand.
@BrianLY-38 Is this a question?

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:

  1. it replicates a existing function, i.e., it’s redundant.
  2. 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.
  3. 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.

2 Likes

@Ohan, I don’t think it’s a question, just a statement of the way the time is passed between map-mode and compare-mode.

2 Likes

Thanks @duane that’s what I was trying to say.

1 Like

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”.)