Quick View should stay on the last selected tab

[MGiacomet]

Tapping on an airport on the map brings up the Quick View pop up. Currently, after selecting a tab of choice and dismissing Quick View, iFly automatically reverts back to the ARPT tab after an (arbitrary) time of about 5 seconds has elapsed.

The request is for it to stay on the last selected tab (be it Wx, ASPC, NAV, etc.) but switch to the appropriate tab if you click on something where the currently selected tab data isn't available. Removing the code associated with the arbitrary 5 second timer is an easy fix (removing code is always easier).

Scenario: You are flying in weather and trying to select the best alternate destination. You tap on a nearby airport and select the Wx tab. Keep tapping on nearby airports to check weather, trying to find one that is good enough for you. All is fine (Quick View stays on the selected Wx tab) until you get interrupted, say by ATC, and 5 seconds elapse between tabs. Voila! Quick View resets back to ARPT requiring you to (re)select the Wx tab, thus unnecessarily adding to the workload.

Steps to reproduce the current behavior:

1. Zoom the map so you can see a few airports that report weather
2. On the map, tap on an airport; pop up will be on ARPT tab
3. Select the Wx tab
4. Dismiss the pop up by tapping somewhere else on the map
5. In less than 5 seconds, tap on another airport that reports weather; pop up will still be on Wx tab. Nice!
6. Optional: quickly repeat steps 4 and 5; pop up will stay on Wx tab for each airport, as you selected
7. Dismiss the pop up by tapping on the map
8. Wait about 5 seconds (simulating you got busy with something else but are not yet done with "hunting" for weather you like)
9. Tap on any of the airports you tapped on the steps above; pop up will now be on ARPT. Would be better if it stayed on Wx

 

[Cobra]

Tap on any of the airports you tapped on the steps above; pop up will now be on ARPT. Would be better if it stayed on Wx

Whether the proposed change "would be better" is a matter of personal preference.

If I recall correctly, the QV tabs used to behave the way you desire. The current behavior (reverting back to the APT tab after a short time) was only implemented after one or more users complained about being unable to select an airport even when tapping right on it. Turns out they had been looking at the NAV tab, and didn't realize they needed to swap back to the APT tab. (I know I got confused by that behavior more than once. I might have even been one of the users who argued for the change to the current behavior--I don't remember.)

I personally prefer the current behavior, and I think it's the more intuitive / "safer" behavior for the typical user.

If this suggestion is implemented, I would hope that AP makes it a user setting, but AP tends to resist adding subtle user settings like this.

 

[MGiacomet]

>>The current behavior (reverting back to the APT tab after a short time) was only implemented after one or more users complained about being unable to select an airport even when tapping right on it
Fair enough but this seems like the fix was poorly implemented. The "hidden" timer (whatever its value be 5, 10, 15 seconds) feels like an easy "fix" to a major problem.

As I stated in my original post: "...switch to the appropriate tab if you click on something where the currently selected tab data isn't available". This would be the best of both worlds.

 

[Cobra]

As I stated in my original post: "...switch to the appropriate tab if you click on something where the currently selected tab data isn't available". This would be the best of both worlds.

This does not solve the problem I described. The NAV tab is valid for every place you can tap on the map. If a user doesn't understand that QV tabs "stick", then they will become frustrated that no matter how precisely they tap on an airport, the QV pops up with a NAV result.

Example:

 

[MGiacomet]

>>If a user doesn't understand that QV tabs "stick", then they will become frustrated...
The same argument could be used for the 5-second timer: A user could ask "Why is it sometimes going back to ARPT?"

So in your case example, you tapped somewhere on the map and selected NAV... Then you tapped on an airport: you are now changing what type of data you are tapping on. In this case, with the proposed enhancement, iFly would change to the ARPT tab because you tapped on an airport.

I really don't get why is it so "important" to always (actually, sometimes) revert to ARPT. If one is peeking at various points for (the choice of) Wx, ASPC, NAV, or ARPT, the tab should stay on the last setting and not "magically" revert back after an arbitrary amount of time.

Not sure what version you are using but when I have NAV selected and tap on an airport, iFly is showing (apparently) the closest FIX. Does that make sense? Probably not because I'm "now" wanting to see info about the airport (that's where I tapped!) and just because the timer hasn't expired, this time it's not giving me the info one needs/expects. Again, with my proposed enhancement, as I tapped on an airport, the ARPT tab would show. Had I tapped elsewhere, the NAV for that point would show (because that's the last tab I had selected)

 

[Cobra]

>>If a user doesn't understand that QV tabs "stick", then they will become frustrated...
The same argument could be used for the 5-second timer: A user could ask "Why is it sometimes going back to ARPT?"

Reasonable people can certainly disagree over which behavior will benefit the most users. I think reverting to the APT tab is the "safer" option that will serve the largest (or confuse the fewest) number of users, but unfortunately it will not be the best choice for everyone, as your post demonstrates.

So in your case example, you tapped somewhere on the map and selected NAV... Then you tapped on an airport: you are now changing what type of data you are tapping on. In this case, with the proposed enhancement, iFly would change to the ARPT tab because you tapped on an airport.

But what if I *want* to get NAV data from that spot? There are often nav fixes near airports--a user may want those, and be frustrated that iFly is forcing the tab to APT mode when they're trying to locate a waypoint or get a LAT/LON reading.

I really don't get why is it so "important" to always (actually, sometimes) revert to ARPT. If one is peeking at various points for (the choice of) Wx, ASPC, NAV, or ARPT, the tab should stay on the last setting and not "magically" revert back after an arbitrary amount of time.

As earlier explained: Because other users had previously complained about the "sticky tab" behavior being confusing.

Not sure what version you are using but when I have NAV selected and tap on an airport, iFly is showing (apparently) the closest FIX. Does that make sense?

It does because that's what how the NAV tab is designed to behave: If there's a fix within proximity of your tap, it will "snap" to the fix. If you tap somewhere where no fix is deemed "close enough", then you get the LAT/LON of your tap.

If you zoomed way into the same airport I used and tapped on the same spot you'd get the same result I did.

Probably not because I'm "now" wanting to see info about the airport (that's where I tapped!) and just because the timer hasn't expired, this time it's not giving me the info one needs/expects. Again, with my proposed enhancement, as I tapped on an airport, the ARPT tab would show. Had I tapped elsewhere, the NAV for that point would show (because that's the last tab I had selected)

But what if you were trying to find a fix that was located near the airport, or wanted the exact LAT/LON of a spot near the airport? Tapping around the airport with the NAV tab selected will get you those results. For that user, iFly auto-switching to the APT tab would be frustrating.

The current implementation may not be a perfect solution, but you can still do what you want even if it sometimes takes an extra tap. Your proposed change in behavior would completely prevent someone from getting the results they want if they were intentionally trying to use the NAV tab near an airport.

 

[MGiacomet]

But what if I *want* to get NAV data from that spot? There are often nav fixes near airports--a user may want those, and be frustrated that iFly is forcing the tab to APT mode when they're trying to locate a waypoint or get a LAT/LON reading.

I think you just agreed with me… Yes the user will get frustrated because iFly ***Is*** forcing the tab back to ARPT after the arbitrary 5-second delay.

But this is a particular use case (not sure why one would be so concerned about fixes very close to the airport, but maybe…)

For the general use case (macro) looking for Wx around not-so-close airports, particularly when you are busy flying IFR in bad weather, remaining on the selected tab (and not having to always think “did the tab change now?”) creates less work

>>As earlier explained: Because other users had previously complained about the "sticky tab" behavior being confusing.

I understand that. I’m proposing a further enhancement but you seem set on defending the status quo. The timed auto reset to ARPT can be considered confusing as well, is not how typical software applications work, is not documented anywhere and creates more work for the pilot.

 

[Cobra]

Despite the number of words I've written on this subject now, I honestly don't feel very strongly about it one way or the other. Mostly I was just trying to share some history.

Based on that history, I think the solution you propose is likely to bother some set of users. My gut feel is that it's not an overall improvement, just a change in which set of users will be annoyed/confused by the behavior, but I don't have any method to prove that one way or the other.

 

[MGiacomet]

As I keep trying to understand the current behavior, I noticed that the 5-second timer doesn’t apply to the NAV tab.

I don’t see the reasoning to revert back to ARPT after 5-seconds EXCEPT when the NAV tab is selected…

Best to keep the last selected tab than have the convoluted logic/timer that reverts back, only for certain tabs.

 

[Cobra]

As I keep trying to understand the current behavior, I noticed that the 5-second timer doesn’t apply to the NAV tab.

I don’t see the reasoning to revert back to ARPT after 5-seconds EXCEPT when the NAV tab is selected…

Best to keep the last selected tab than have the convoluted logic/timer that reverts back, only for certain tabs.

???

No, the behavior is the same for the NAV tab. I just demonstrated it on my device.

 

[MGiacomet]

???

No, the behavior is the same for the NAV tab. I just demonstrated it on my device.

You are correct.

So, my feature request is simply to remove the timer that resets back to ARPT. If a tap happens anywhere and the selected tab doesn’t have data to display, then revert to ARPT

Let’s see what others think

 

[MDreger]

I just tried it in the Windows 13.3.53.

I tend to agree with some of the suggestion.

It seems the 5 second time out is a bit quick, but I don't know what the appropriate time out duration should be.

I'd like to see the behavior change to:

If you have clicked on an airport, read the QV Tab you want, then click on another airport it would close the first QV window and display the new QV with the last Tab selected. As it is now, it takes two clicks to get the QV to open any subsequent tabs. Clicking on some random place would simply close the QV, unless you were looking at the NAV Tab, in which case it would display the QV for the new point.

 

[Cobra]

If you have clicked on an airport, read the QV Tab you want, then click on another airport it would close the first QV window and display the new QV with the last Tab selected. As it is now, it takes two clicks to get the QV to open any subsequent tabs. Clicking on some random place would simply close the QV, unless you were looking at the NAV Tab, in which case it would display the QV for the new point.

This would either:

1. Imply that tapping somewhere on the screen changes you to "QV Mode", and that mode would persist until you clicked a "Close" button on the QV window or something.
   or
2. Result in different behavior depending on which tab you select, as to close the QV window when using the "APT" or "WX" tabs would only require tapping somewhere other than an airport or weather location, but you'd never be able to close the QV window when using the NAV tab since every point on the map will give a NAV result of some sort

 

[MGiacomet]

I just tried it in the Windows 13.3.53.

I tend to agree with some of the suggestion.

It seems the 5 second time out is a bit quick, but I don't know what the appropriate time out duration should be.

I'd like to see the behavior change to:

If you have clicked on an airport, read the QV Tab you want, then click on another airport it would close the first QV window and display the new QV with the last Tab selected. As it is now, it takes two clicks to get the QV to open any subsequent tabs. Clicking on some random place would simply close the QV, unless you were looking at the NAV Tab, in which case it would display the QV for the new point.

Thanks! Don't forget to upvote if you like the idea

As far as timeout... timeouts are always bad in programming (40+ years of Software Engineering, here): they'll always come back to bite some time (pun intended) in the future. The best practice is to let the user be in control, not have "magic" happen unexpectedly after some time

I tend to agree with you on the last part but also with Cobra on his reply. Can we have a third option? Here's an idea: We have the "Close" button to dismiss Quick View (that's one way of dismissing) and, to combine your idea with the current behavior, the secondary way of closing Quick View could be to tap on the same airport you tapped to open Quick View (instead of anywhere on the map)