I remember seeing this update on some machines I set up for work and wondering the same. It occurs the first time the clock app is launched, and the “update” is really just pulling the time zone data and setting the clock to what is accurate (internet based world clock), seperate from the bios time it was going off of prior to that. It’s really just looks worse than it is.
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.
So why does that need a whole new clock app? That would just be an update to
tzdataon a Linux system.Windows
I remember seeing this update on some machines I set up for work and wondering the same. It occurs the first time the clock app is launched, and the “update” is really just pulling the time zone data and setting the clock to what is accurate (internet based world clock), seperate from the bios time it was going off of prior to that. It’s really just looks worse than it is.
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.