Using Scriptable on iOS 14 to Show Real-Time SL Departures in a Widget

I finally got around to playing with the Scriptable app, something that had been on my list since I heard about the app’s newest ability — letting you turn custom Javascript into iOS 14 widgets.

The obvious place for me to start was to try and replicate the departure boards you see at Stockholm’s bus stops, since I had (very recently) also tried to write a macOS screensaver that would do just that, before life got in the way. Continuing that abandoned project in what seemed — and, as my experiments showed, definitely is — a “friendlier” environment seemed like the logical thing to do.

Getting started with Scriptable was pretty simple, thanks largely to the sample scripts within the app, specifically the View JSON and News in Widget scripts which do exactly what their names suggest. Taking the relevant bits from the two scripts and pointing them to SL’s awesome real-time API was as easy as I thought developing the screensaver would be.

I’ve released the script as a Gist (and embedded it below), and here are some thoughts on Scriptable and writing widgets on iOS 14, as well as the script itself:

  1. This is very much a quick-and-dirty script put together in a couple of hours, and is specific to my use case as someone who lives close to a bus stop (and no train line nearby) but hates waiting there. The idea is to monitor upcoming departures at a specific bus stop in one direction so I can time my own departure from the house to minimise waiting. It should be trivial to customise the script for a more generic requirement.
  2. I use a pure black background as my iPhone wallpaper, hence the motivation to use a pure black background colour for the widget. With that said, though the screenshot shows the widget being used on the home screen, I don’t foresee continuing to use it like this on a daily basis largely to the fact that there’s no way (that I’ve come across) to force the widget to update periodically (every minute would be ideal). Which is why I was forced to add the “Updated:” bit in the footer, so I know how dated the information that I’m looking at is, and to manually run the script again (which shows the updated widget as a popup), if necessary.
The widget in action on iPhone and iPad
  1. Scriptable offers plenty of options that let you customise the look and feel of the widget but I didn’t bother experimenting with most of those. Ideally, I would love for the widget to look exactly like the boards you see at bus stops — the “stacks” added in the current TestFlight build should make it easier to do stuff like that — giving this very much “functional” widget some much-needed “whimsy”.
  2. As you can see I went the good-old fashioned “tabs and fixed-width fonts” route for formatting. For some reason using “regularMonospacedSystemFont” wouldn’t return a fixed-width font (as I understood it should), so I ended up hardcoding the font name itself, though Menlo wouldn’t have been my first pick otherwise. If you know why the regularMonospacedSystemFont approach didn’t work, please let me know via Twitter or the comments.
  3. I did all the development on the iPad (Scriptable of course is available for both iPhone and iPad) and while the development process itself was pretty straightforward, figuring out how to add a Scriptable widget to the ‘Today View’ when I was done took a lot more time than I’m willing to publicly admit. I kept looking for Scriptable under (what I now know is the old) list of widgets you see when you go to Edit > Customize from the bottom of the Today view. Maybe it’s just me, but that “+” sign to add iOS 14-only widgets is really easy to miss, especially when you are in landscape mode (which is how I use the iPad 99 percent of the time).

While it’s convenient to have this information on the iPhone and iPad, the need to build that screensaver still remains — the idea is to have the Macs in the house act as giant departure boards you can glance at while getting ready. I hope to return to development soon and add to my screensaver collection of one.

HomePod Finally Available In India — Thoughts Of A Long-Term User

The HomePod is finally available in India, roughly three-and-a-half months after Apple announced its India launch and released a software update that enabled Siri support for English (India) on the device. The Rs. 19,900 price tag is a pleasant surprise if you compare it to the official price in the US ($299), but it’s exactly what you would expect if you take in the unofficial market price, which stands at $199.

I’ve been using a HomePod — in both India and Sweden — since March 2018 and my experience is pretty much in line with what you might have read elsewhere. In a nutshell, it’s by far and away the best-sounding smart speaker available in India right now. While the newest high-end Echo devices feature much-improved sound quality, nothing comes close to the richness, clarity, and sheer loudness that the HomePod can offer.

However, Siri’s well-documented shortcomings mean that it, sadly, falls short as far as the “smarts” are concerned. While adding support for English (India) means that the HomePod is now as good as Siri on iOS in understanding Indian accents and ‘Indianisms’ (like Bollywood song names), its ability to offer useful answers and information is just as limited as that of the iPhone.

At home, we use our HomePod regularly to set timers and to look up weather, something we’ve been doing a lot more frequently since we moved to Stockholm, as the weather plays a much bigger part in day-to-day lives in this part of the world. Other HomePod features like personal requests, Siri Shortcuts, and HomeKit-support haven’t gained any traction in our household.

The boy will ask Siri to play the occasional tune, but I’ve noticed he now turns to Alexa more often, probably having been scared by the “Sorry, I’m having trouble…” response that the HomePod used to give every once-in-a-while until I figured out how to solve the problem for good (more on that in a later post). Of course the real reason he turns to the Echo Spot for his music requests is that he likes seeing lyrics as he’s listening to a song, and that he doesn’t mind the tinny sound.

But the most use we get out of our HomePod every day is by using it as a speaker for our Apple TV over AirPlay. We’ve been cord-cutters for the best part of a couple of years now, which means we do 100 percent of our TV viewing via the Apple TV, and the HomePod is our audio output device of choice.

Minor annoyances aside, this works really well, and at various points I’ve considered adding another HomePod to the setup, what with $199 sales extremely common in the US, and enjoying a true stereo pair. The only thing that’s stopped me from doing that is long-term — and I mean really long-term — question marks over the utility of the product.

I’ve already invested nearly $400 in a HomePod (yes, I am one of the “suckers” who bought it at full retail prices when it first launched in the US) knowing fully well that this device will one day become a very expensive (albeit beautiful) paperweight.

One day, in the mid- to long-term future, Apple will stop shipping HomePod firmware updates. And some day, Siri will no longer work on the device because Apple has moved on to a new voice-based assistant. And finally, WiFi and AirPlay standards on the HomePod will go out of date and will no longer be compatible with the digital infrastructure of the time.

Once all that happens — and that day will surely come — the HomePod, like many other smart devices that rely entirely on modern interfaces like wireless audio, will be completely useless.

Which brings me to the biggest thing I wish the HomePod did differently — it should have shipped with an aux-in port. I know that makes me sound like the one dude who still complains about the iPhone’s missing headphone jack (hi, @reckless) but it’s the inclusion of this “legacy” port that would’ve made the HomePod a truly “future-proof” product. Let me explain.

Before I cut the cord and switched entirely to the current Apple TV + HomePod setup, I had a whole host of devices connected to an A/V receiver. And the device I was using for my audio needs was a Cambridge SoundWorks Radiio CD 740 unit that I love for the same reasons I love the HomePod — it’s relatively compact (for what you get), and the sound quality is top-notch.

I paid top dollars for both products at purchase (and didn’t mind doing that for the most part), but I can’t imagine I will have my HomePod hooked on to my TV in 2038, the same way the 740 I bought nearly twenty years ago is still connected to my TV back home in India — all thanks to the good-old aux-in port.

Of Google Hotel Finder and comparing Apple, Microsoft & Google

In an interesting critique of Google Hotel Finder, these lines stood out:

As Google grows, its willingness to float bad products is starting to seem a little bit similar to Microsoft, ten years ago. You know what’s also similar? Its dependence on a single cash cow that keeps them from caring whether any single side venture lives or dies.

Which leads us to:

The direct contrast of course is America’s best design-driven company, Apple. Steve Jobs would rather die than release any new product that wasn’t a step-wise improvement over everything that existed before. That’s the mentality of someone that cares about whether people use a product. It’s the mentality of a designer. Google’s mentality is that of an engineer, content to labor over one cool feature at the expense of creating any overarching value.

And finally:

As the example of Microsoft vs. Apple showed us, the engineer’s mentality can win early in a product cycle, when new features can create great advantages over competitors. But over time, as the tech gets commoditized, it’s companies like Apple, which are focused on integrating all the features, that create world-changing products.