Yeah but that shouldn’t be so data or read/write intensive that you need an entire splash. Should take less than a second on any hardware capable of running w11.
Is it just doing some weird backend patching to make it compatible with the rest of windows somehow?
It makes sense in a weird way, but it doesn’t feel right for a clock. You need to account for the case where it does take longer than it should to update, because sometimes it will for any number of really weird reasons. So you can’t just design for the best case scenario.
Now that you have a splash screen you need to ask yourself if it’s better to show the splash screen while doing the update, or to just let the app be unresponsive for the common case of a moment and then show the splash if it goes over that.
The answer is to show the splash in the common case too.
Now people are seeing a “weird screen” for a moment before they can process what they’re seeing. So you need to make the screen have a minimum display time to keep people from being confused.
It’s weird, but people can sometimes be more confused by thinking something happened too fast.
Not that I’m thinking about it I bet it’s because the clock is a local app when the OS installs, but if you sign into a Microsoft account they probably re-install the clock from a Microsoft Store version. Which would give it the ability to auto sync features pertaining to your calendar and shit. So items you put in your Microsoft Planner will integrate automatically. Meaning of you use a local account there is likely no update, but if you sign in all your tasks, calendar items and shit likely automatically populate into it.
Bet they tried to integrate it into copilot or something as well, so like in Android if you told Google assistant or Gemini to set an alarm it is able to add it directly to you calendar and such.
Good arguments for any given program, just hard to imagine they’re still valid for a clock. There’s no other example i can’t think of that a clock has noticeable startup delay or even update time. In the most charitable wording this is exceptional, a unique example amongst the broadest class of programs.
I now realize it’s probably not worth attempting to convince me to not be cynical, i’m having as much trouble as OP with this lol. Thanks for your thoughts though.
Oh, don’t get me wrong. It’s odd for a clock to act this way, just not inexplicable. At best it’s an example of UI standards being applied without regard to sense, which is very much in line with Microsoft.
Most other clocks will do something similar, they just do it in the background. Something that’s a lot easier to do if you’re not following a UI framework that says you’re never allowed to change something in a way that might cause the user to see a weird shift. Other things just acknowledge that clock sync should only take a few milliseconds before the clock is even visible, that a timezone DB update will rarely cause a change of more than an hour, and that a user will probably not even notice if there’s a shift.
Yeah but that shouldn’t be so data or read/write intensive that you need an entire splash. Should take less than a second on any hardware capable of running w11.
Is it just doing some weird backend patching to make it compatible with the rest of windows somehow?
You’re right, it should just cURL a JSON but this is Microsoft
It makes sense in a weird way, but it doesn’t feel right for a clock. You need to account for the case where it does take longer than it should to update, because sometimes it will for any number of really weird reasons. So you can’t just design for the best case scenario.
Now that you have a splash screen you need to ask yourself if it’s better to show the splash screen while doing the update, or to just let the app be unresponsive for the common case of a moment and then show the splash if it goes over that.
The answer is to show the splash in the common case too.
Now people are seeing a “weird screen” for a moment before they can process what they’re seeing. So you need to make the screen have a minimum display time to keep people from being confused.
It’s weird, but people can sometimes be more confused by thinking something happened too fast.
Not that I’m thinking about it I bet it’s because the clock is a local app when the OS installs, but if you sign into a Microsoft account they probably re-install the clock from a Microsoft Store version. Which would give it the ability to auto sync features pertaining to your calendar and shit. So items you put in your Microsoft Planner will integrate automatically. Meaning of you use a local account there is likely no update, but if you sign in all your tasks, calendar items and shit likely automatically populate into it.
Bet they tried to integrate it into copilot or something as well, so like in Android if you told Google assistant or Gemini to set an alarm it is able to add it directly to you calendar and such.
Good arguments for any given program, just hard to imagine they’re still valid for a clock. There’s no other example i can’t think of that a clock has noticeable startup delay or even update time. In the most charitable wording this is exceptional, a unique example amongst the broadest class of programs.
I now realize it’s probably not worth attempting to convince me to not be cynical, i’m having as much trouble as OP with this lol. Thanks for your thoughts though.
Oh, don’t get me wrong. It’s odd for a clock to act this way, just not inexplicable. At best it’s an example of UI standards being applied without regard to sense, which is very much in line with Microsoft.
Most other clocks will do something similar, they just do it in the background. Something that’s a lot easier to do if you’re not following a UI framework that says you’re never allowed to change something in a way that might cause the user to see a weird shift. Other things just acknowledge that clock sync should only take a few milliseconds before the clock is even visible, that a timezone DB update will rarely cause a change of more than an hour, and that a user will probably not even notice if there’s a shift.