Scheduling Page

[Tiberius]

Can we get scaling on the scheduling page..ie the old page would scale text for very short routes with small blocks so you could still see it in tiny text.  The new page cuts it off completely.

Also, is the font right? It seems harder to read than the old page...maybe its more narrow? or less space between letters?  Any thoughts.

Bonus: Can some adjustment be made to dark mode.  For example, on this text field, in dark mode, I am typing in grey with black text (nearly complete blackness).  I have noticed one or two other places like that with light/dark dark mode glitches.

Thanks!

[Sami]

The flight block (blue bar) does show the destination airport when it counts that it can fit there fully (i.e. airport code fully fits inside the flight's blue bar). If the flights are really short the label is omitted. If you can point examples on old vs new where you should see the labels then I can perhaps adjust (if possible).

[JumboShrimp]

Can we get scaling on the scheduling page..ie the old page would scale text for very short routes with small blocks so you could still see it in tiny text.  The new page cuts it off completely.

Also, is the font right? It seems harder to read than the old page...maybe its more narrow? or less space between letters?  Any thoughts.

Bonus: Can some adjustment be made to dark mode.  For example, on this text field, in dark mode, I am typing in grey with black text (nearly complete blackness).  I have noticed one or two other places like that with light/dark dark mode glitches.

Thanks!

If you have not already, you can switch to 3 latter IATA airport codes, for instant 25% width reduction and equal readability

[Tiberius]

If you resize the window you can see how it adjusts...it tries to scale a bit on the old scheduling page, so its more readable on a small window. Some are small, like KASE, KBIL. But almost all are readable.  Compare to new, can't read very many of them.

When I enter text it looks like the image I attached.

[Sami]

The old page is clearly wrong there as the text jump over the flight's blue bars and do not stay inside them. But maybe I can squeeze the font in the new page a bit too.

[Tiberius]

Thanks for checking into it.  Just looking for a bit more readability if possible.  Appreciate all the updates!

[schro]

Can't tell the right place to file a grievance for this, so here I am. The new scheduling page is unusable on mobile, full stop. My browser as the visual impared/force zoom feature on, which could be the cause of it, but I can't do any sort of adding of routes. For example, I click the + add route button, then I have to move the modal into view, which usually registers a click on the edge, which closes the modal. Then if I do avoid doing that, it's near impossible to scroll (i.e. I have 21 routes available intended for 3 planes, trying to check box 7 specific ones usually results in the modal closing one me before declaring victory).

[Jack Ruskin]

In the new scheduling page, when transferring the schedule to another aircraft, and there is a problem, for me it was that an airport was closed at the new aircraft's arrival time, the warning box displays the ICAO (4 letter code) airport code only, which, if you're using IATA (3 letter code), doesn't help you. Could it be amended to show both airport codes?

[Sami]

My browser as the visual impared/force zoom feature on

Hmm, explain this a bit more, so that I could see and test it myself?

(Since no problems without such settings)

In the new scheduling page, when transferring the schedule to another aircraft, and there is a problem, for me it was that an airport was closed at the new aircraft's arrival time, the warning box displays the ICAO (4 letter code) airport code only, which, if you're using IATA (3 letter code), doesn't help you. Could it be amended to show both airport codes?

Have to correct it to show the proper format based on your selection (not both). Edit: This is fixed now.

[Stefan]

Hi Sami.

I have two requests. 

First, in the new version, only 3 or 4 flights are visible during flight assignment, although they are very detailed. Previously, more than a dozen were visible, albeit without details. When I want to assign many flights to 7/7 schedules, it now takes me significantly longer to scroll through the routes and click the right ones for the aircraft. It would be great if (a lot) more flights were visible again during selection. Maybe the details could be placed on the same line next to the flight number.

Secondly, the new system responds very sluggishly (PC). When adding or removing a flight, I get the impression that I am now waiting 2 to 3 times longer for the data to process. Even though it's only a few seconds each time, it really adds up when dealing with many flights. It would be nice if the performance didn't fall behind the old version.

Thank you.

[Sami]

For item 1, change airline settings to use the compact view for Add Flight menu to view more at a time (this was mentioned in the public news I posted too). So see path Dashboard - Airline Settings - Interface - Scheduling.

(The Add Flight menu will be tuned a bit more over the weekend)


For second item. What computer / device you have? And which exact action or part of the page are you referring to, or just to the main scheduling page's loading time?

I have measured the new page's main scheduling loading times on multiple devices, and many different airlines, and the main schedule listing loads some 30-50% faster than the old one consistently (from zero to full data visible to user). I don't have the exact numbers here (as I'm not on computer right now), but I remember one test resulted that a large airline (>500 a/c, and 75 planes per page) had the old page loading fully in 2.5 sec while new page takes 1.5 sec (this includes the full page render at user browser too, not just backend server time).

But there might be some hidden issues still somewhere? ...thus, requesting more info on this - where does it happen and on what device and during what functions (etc.etc.), so I could take a closer look?

[schro]

Hmm, explain this a bit more, so that I could see and test it myself?

(Since no problems without such settings)

Took a screen capture video, will DM you a link as it's too big for the forums.

The only way to move around the screen is to zoom/unzoom/rezoom. Any glancing touch outside the modal will close the modal. The button on the bottom to confirm the flight ads is covered. The menu flyout takes two clicks to open.

Original post was probably mostly frustrated at the modal closing if you look at it wrong.

[Sami]

Yes the "click outside modal to close" is a deliberate and common design choice. I'll take a look at your video over the weekend and see if there are some tricks to be done to improve.


The UI looks also otherwise a bit skewed, so you had some extra zoom and also some other settings applied too?
(for example the main navigation and the airline status bar aren't normally placed like that; so I wonder if I can do the same setup to my test device? Which device / resolution is that normally, and how would I activate similar aids to it?)

[schro]

Samsung S25 Ultra 2340x1080 resolution.

So, it seems the root cause of this is that I have "Desktop Site" set in Chrome so I get served the desktop page instead of the mobile page (site specific configuration). The only other adjusted setting is Accessibility -> Enable Forced Zoom (this is global). I likely set it this way a very long time ago as the UI was simply better to me to use the desktop view on mobile - fewer clicks, everything in its place, and I'd just zoom into whatever it is I wanted to do.

That being said, turning off desktop mode gives me a much better experience on the scheduling page (and I've got a plane arriving shortly that I can try it on).  Though, quite frankly, I think I still prefer desktop mode over mobile... and wouldn't be shocked if it was declared as unsupported.

[Sami]

Okay, that explains it then rather well. The airline statusbar/menu got me indeed wondering...

The mobile layout is good, and coming to all pages one by one. So there's really no use for the forced desktop mode anymore since it creates more problems on small screens and touch devices than it solves, and no compatibility or functionality can be guaranteed.

Anyway, I will still look into improving the overall tech of modal dialogs on mobile, since there are a few minor things with them that aren't yet fully perfect (especially for the case where the modal content grows too large vs. available screen size).

[Stefan]

I have tried it on various PCs. For example 11thGen i9-11900K,64GB,RX7900XTX,Windows11Pro, but I haven't tested it on smartphones.
I switched to standard browsers like Edge, Opera (Chromium) and Firefox (Gecko), which makes the processing faster but delay always occurs whenever the display below comes into play (so when removing, deleting, and adding flights).
If I am alone in noticing this, then I shall learn to live with it. 

[Sami]

I have tried it on various PCs. For example 11thGen i9-11900K,64GB,RX7900XTX,Windows11Pro

More power than what I got, so that's not the issue then.

What function in the scheduling in particular? The loading of the page, some sub-action (add flight, remove flight, move schedule), or something else? And can you describe more or get me video somewhere to see how it looks, or give me step-by-step replication on how I can see it myself if I access your airline? (and which game is in question, or all of them?)

Do you have any browser extensions or other similar "non-standard" things that could cause this? Probably not since if you tried with multiple browser, then I think it might be server backend slowness.

The blue dots "loading screen" shows up when a) request is being sent to server and processed at server and b) the response from server is being set up for display by your browser. So delay can be caused by either of those.

For our backend server delay, check what the "Processed in xx sec with xx db queries" at the bottom right corner of the page says after you experience such a loading delay? (if you have the modal window open, you have to close it first, without reloading the page).

Anything less than 0.5-1.0 sec process time is ok, and anything above that is not acceptable for normal use and repeated tasks.

[Stefan]

The delay occurs in both current editions: HAF26 and AOF25.
e.g.
Routes->Scheduling->HQ:EWR->first plane with routes 737-300->clear schedule->"Are you sure" CONFIRM -> Delay > 1.5s-2s, Proccesing time 0,18s (ok)
Routes->Scheduling->HQ:EWR->first plane with routes 737-300->add flight->mark "All flights" and CONFIRM -> Delay > 1.5s, Processing time 0,16s (ok)
The same times occur when deleting and adding individual flights, and also with "Set Maintenance Schedule".

With the old Scheduling: Processing time 0.02s (for all actions)

I only just noticed that the processing time is very good. Thank you for pointing that out. The increase from 0.02 to 0.18 should hardly be noticeable.
Therefore, the issue is clearly on my end. We have made significant changes to our network security both at home and at work, which might be related to these delays.
However, it is still noticeable that the "old" scheduling is 2-3x (half a second instead of 1.5 - 2) faster for me in the exact same environments. I can only hope that the old flight schedule management stays online for a little while longer. 
Thanks for your help, Sami!

edit: down from 0.18s to 0.04s (real from 1.5-2 to about 0.5s) That´s a game changer for me! Thank you!

[Sami]

edit: down from 0.18s to 0.04s (real from 1.5-2 to about 0.5s) That´s a game changer for me! Thank you!

I've done no changes since I last posted on this thread. Strange 

Though could it be possible that some earlier change I made on Wednesday evening was something you hadn't yet seen / tested? (they have been already in effect from wednesday evening EU time)

Anyway, I will do further analysis on this over the weekend. And do note that I have to do a minor test with your actual airline on the actual game too, to be sure I am seeing same results (since test server, even though it has the same data, might not give same backend processing time results). So if you suddenly see that a flight was unscheduled, and then appears back, you'll know it was me. But it'll only be for 30 seconds max and for one aircraft (like you described)


Also, one thing that could be useful to check, if the page is fast/normal when you first open AWS, and when you are inside the game for longer and click around for a long period, does it get slower? Thus indicating some cache/memory issue. Unlikely, but anything is always possible, so keep an eye on that.


Also, have to note that the old scheduling page does NOT update the lower-corner "processing" timer, so that's not comparable. It fully only works on new pages - just FYI. But the new page seems good anyway, so not a backend or database issue from what I see.