2024-10-06, 20:39
I prefer the new implementation over the previous one!
2024-10-06, 20:57
I wouldn’t say loss, just different. From a usability standpoint you could view the now playing while having a panel open but off to the side. You couldn’t interact with now playing with the panel off to the side but you could see it. Doesn’t really matter much to me. My opinion means nothing since I’m not a real user of iPad version. 🙂
2024-10-07, 10:18
(2024-10-06, 20:57)amasephy Wrote: You couldn’t interact with now playing with the panel off to the side but you could see it.Exactly my thought as well -- no interaction possible anyway. The other thing I removed was the "drop card" function which allowed the user to remove the top view by pulling it quickly out of the visible area.
Except the iPad stack rework, the profiles support (which still needs some conceptual thinking and decisions) and some other not so important stuff, all other changes have a PR now and are ready for review. Quite a lot again, but many few-lines changes improving/fixing glitches found recently.
2024-10-07, 13:31
Came across some optimization for the time to connect. It is more or less instant now. The videos show start to connect, followed by selecting a new server. The server is connected once the menu items are not grayed out anymore (hardly visible anymore).
It is so fast that I am even thinking of slowing this down a bit. Users might be irritated.
2024-10-07, 16:18
I really hope you are joking about artificially slowing it down.
This speed optimization seems like one of the best new features introduced in awhile. I definitely want the instant connect feature!
This speed optimization seems like one of the best new features introduced in awhile. I definitely want the instant connect feature!
2024-10-07, 17:08
I was not joking, but maybe I can explain better what concerns me. With the optimization, you hardly see the server list and impossibly can read anything as it is closing that quickly. It looks more like a glitch or flickering. This could irritate users and let them assume something went wrong somehow. There I have in mind to delay the closure of this panel. The easiest would be to just delay the connection by 0.5 - 1.0 seconds.
Of course I can also wait and see how the reactions are via TF.
Of course I can also wait and see how the reactions are via TF.
2024-10-07, 18:06
I think I understand what you are talking about.
Maybe you don’t really even need to show the server list view to start. Only show it if a connection can’t be made.
Connecting to last server seems like a good default. Server name is always visible anyway.
Maybe you don’t really even need to show the server list view to start. Only show it if a connection can’t be made.
Connecting to last server seems like a good default. Server name is always visible anyway.
2024-10-07, 18:10
I thought about the same. Requires more changes though, as this is not how the current implementation is intended to work.
2024-10-07, 18:12
A TF build with this will definitely give us a better impression.
Also maybe a toast notification indicating server connection established might be more graceful than briefly displaying the server list screen which feels more like a hack where someone was using a tool like autohotkey to automate actions.
Also maybe a toast notification indicating server connection established might be more graceful than briefly displaying the server list screen which feels more like a hack where someone was using a tool like autohotkey to automate actions.
2024-10-07, 18:19
The toaster message is an interesting idea. And a hotkey macro is a good comparison to how this currently look. As said, a quick solution would be to add a small delay to keep the screen visible for a reasonable time. This is still a lot faster than before.
2024-10-07, 19:27
To share a few numbers measured from app init to "connected":
The 0.2 sec is what you see in the current video. I am quite sure I can change the implementation to reconnect the last mode in a different way. I just need to understand the effect to the UI better.
But the improvement is already quite drastic -- even with a short delay to let this look too glitchy ...
Code:
model | time before | with short delay | fastest
iPhone 14 Pro | 5.1 sec | 1.2 sec | 0.2 sec
iPad 8G | 10.2 sec | 2.0 sec | 0.3 secThe 0.2 sec is what you see in the current video. I am quite sure I can change the implementation to reconnect the last mode in a different way. I just need to understand the effect to the UI better.
But the improvement is already quite drastic -- even with a short delay to let this look too glitchy ...
2024-10-07, 19:34
Wow! I always wondered why it took so long for the App to reconnect. Even more eagerly waiting for the next test flight now!
👍
👍
2024-10-07, 19:39
Definitely impressive results. Since you are already diving into this, my vote is to go all the way with it and overhaul how it connects and presents this info to the user. We can wait for the TF. 🙂
2024-10-07, 20:56
It was worth the work. Videos show sequence of
The connection is done before the UI is animated in on iPad. Shocking fast. The only visible glitches on iPad is the playlist fade out/in on and on iPhone, when not starting into main menu per default, a quick slide out of the server list before sliding in the new view.
- Clean start with non-available last server
- Clean start with no server selected
- Change to server 1
- Clean start with server 1
- Change to server 2
- Clean start with server 2
The connection is done before the UI is animated in on iPad. Shocking fast. The only visible glitches on iPad is the playlist fade out/in on and on iPhone, when not starting into main menu per default, a quick slide out of the server list before sliding in the new view.
2024-10-07, 21:26
Is there really nothing that can be done about not starting in main menu for iPhone? If not, this is really a disappointment.
Might you be able to investigate improving the logic used for not starting in main menu? Again, this is sounding like the macro action thing we spoke of earlier. Reminds me of the whole UI shouldn’t be concerned with app logic paradigm.
Might you be able to investigate improving the logic used for not starting in main menu? Again, this is sounding like the macro action thing we spoke of earlier. Reminds me of the whole UI shouldn’t be concerned with app logic paradigm.
