September 19, 2020 at 8:26 AM by Dr. Drang
Apple has been doing public betas for its operating systems for five years now, and I can’t say I’ve seen any improvement in the quality of the software that’s come out since then. If the public beta program were an experiment, I’d be tempted to call it a failure, but only if software quality were the point. I doubt that it is.
It’s probably too early to assess the quality of the initial releases of iOS/iPadOS 14 and watchOS 7, but there are some troubling stories about data failing to sync across devices and crummy battery life (especially on watches). Even if the OSes themselves turn out to be of decent quality, the release was handled poorly. I’m not sympathetic to third-party developers who didn’t get their products prepared over the past few months, but by announcing on Tuesday that the release would be Wednesday, Apple forced all the third-party developers into a one-day fire drill that will lower the overall quality of software on iDevices for a couple of weeks, at least.
Of course, the reigning king of poor initial OS quality is iOS 13, whose many, many, many early releases would have been reminiscent of a silent movie comedy were it not for the loud groans coming from its users. But iOS 13 also had the great counter-example to public betas: the cursor/pointer support in iOS 13.4. Here was a major update kept hidden in Cupertino until it was sprung on the world in late March, and it pretty much just worked right from the start. Yes, there were apps that couldn’t use cursor support, but they didn’t lose functionality when it came out. I don’t recall stories of anyone suffering under iOS 13.4. Somehow, Apple managed to test it very well internally.
Which raises the question: what is the point of the public beta program? Is it really intended to improve the quality of the released version? If so, why do we keep hearing of bugs that are reported but persist throughout the beta cycle? Whatever its original purpose, the public beta program is now a marketing tool—a way to get Apple enthusiasts hyped about the new releases and hyped to buy the new products that come out alongside the new software.
September 12, 2020 at 9:08 AM by Dr. Drang
I don’t want to keep talking about dates in Shortcuts, but I keep learning new things.
Yesterday, I said
As for the Shortcuts bug, it’s something I should have found in testing right away. Although the Ask for Input step at the top of the shortcut allows me to choose a date other than the default of the current date, the event that gets added to my calendar is always three weeks after the current date. No matter what I change the date to in the picker. Kind of makes the picker pointless.
This was wrong. There is no bug in the date picker. The source of the problem was a date parsing error later in the shortcut.
This morning, I was thinking about this “bug” and decided it didn’t make any sense. If the date picker didn’t work, surely there’d have been an outcry long ago; I wouldn’t be the first to run across it. So I started testing.
Here’s the simple testing shortcut:
I started out setting the custom date format of
Provided Input in Step 2 to the format Tony suggested:
yyyy MM dd 21:00:00.
When the date picker came up, I set it to September 10.
And the alert popped up with the time I wanted, 9:00 PM, but the date set to September 17—five days from today, not five days from the date I chose in the picker.
Adding hyphens to the custom date format,
fixed the problem. That weird format Europeans like,
dd MMM yyyy 21:00:00
also worked. Both of them gave a result of “Sep 15, 2020 at 9:00 PM” when I chose September 10 in the picker.
While I understand that there are limits to what Shortcuts can parse, I don’t understand the reversion to the current date when the parsing fails. By the time we get to the second step, Shortcuts should already know that I’ve chosen September 10 in the picker. But whatever the reason, the upshot is this: If you’re going to use a custom format to adjust a date or time, use the simplest format you can for the part that isn’t getting adjusted.
September 11, 2020 at 9:04 AM by Dr. Drang
After last week’s post on my contact lens calendar shortcut, a couple of readers tweeted1 me other ways to deal with dates in Shortcuts. I want to talk about one of them and how I used it in my rewrite of the shortcut. The rewrite was inspired less by the change in how the dates get parsed and more by a bug in another aspect of Shortcuts’s date handling. I’ll talk about that, too.
I am not a purist when it comes to variable typing. For many years, I programmed in Perl, where a string is a string, unless it looks like a number, in which case it’s a number, unless you treat it like a string, in which case it’s a string. You don’t hear Perl programmers talk much about language orthogonality. But I do find it distasteful to use a formatting command—which is there to set how the date and time are displayed as strings—to change the date and time themselves.
What bothers me most about this feature, though, is that it’s basically undiscoverable.2 Which gets to my main complaint about Shortcuts: its documentation is “try it and see.” That’s fine for a video game but not for a programming language.
Ultimately, I know I’ll get over my distaste, as using formatting to change a date or time can be really powerful. Thanks to Tony for teaching me this one weird trick.
As for the Shortcuts bug, it’s something I should have found in testing right away. Although thestep at the top of the shortcut allows me to choose a date other than the default of the current date,
the event that gets added to my calendar is always three weeks after the current date. No matter what I change the date to in the picker. Kind of makes the picker pointless.
Since I can’t fix the bug, I need to work around it. This got me thinking about how I expect to use the shortcut and whether I need the date picker at all. As I said in the original post, I expect to run this shortcut in the evening when I throw a set of contact lenses away. If I forget to do it then, I’ll run it the next morning when I start a new set. So I don’t really need to be able to choose any date. When asked for when I threw my contacts away, I just need to be able to answer Today or Yesterday. That calls for a menu, not a date picker.
With that in mind, here’s the new Contact Lens Calendar shortcut:
|1||Get today’s date.|
|2||Choose the day I threw away the last set of contacts.|
|3||If it was today…|
|5||If it was yesterday…|
|6||Get yesterday’s date…|
|9||Now get the event date three weeks from
|10||And get the day after
|11||Create an event for 9:00 PM with an alert. The event’s Notes tell me when I started wearing the current set and remind me to run this shortcut again to set the next event.|
This is longer than the original shortcut, but it’s easier to use. And it actually works, which is helpful.
I’m basically off Twitter. I do follow links that take me to Twitter’s website, and when I’m there I do look at my notifications. But email is really the best way to get in touch with me now. ↩
It’s tempting to say this is part of Apple’s continuing trend toward hidden features—of a piece with long presses vs. long-but-not-that-long presses and swipes up from the bottom vs. swipes up-but-not-that-far-up from the bottom. But Shortcuts’ opacity can’t be blamed on Apple’s current design culture; it was a ball of undocumented features back when it was Workflow. ↩
September 9, 2020 at 5:33 PM by Dr. Drang
The only question I want asked of the legendary journalist while he goes on another of his legendary promotional tours, is whether he ever ran across, in one of his legendary deep background interviews, anyone who estimated how many Americans died because he sat on Trump’s lies for six months to avoid spoiling his legendary book and depressing its legendary sales.