This week's sponsor
All Natural Contact - The user friendly, time-saving way to keep up with your team's most important contacts.
By Jason Snell
February 23, 2017 11:34 AM PT
Overcast 3 came out earlier this week, but I’ve been using a beta version for a while, and it’s changed the way that I plan my podcast playlist.
(First, I should say that if you’re someone who wants to carefully curate your podcast playlist, you should check out Supertop’s Castro, which is designed around personal curation and triage of podcast episodes. Overcast 3 makes triaging episodes easier, but Castro is all-in on the concept.)
Here’s how I used to use Overcast: I kept a playlist called The Playlist and almost every podcast I subscribed to would dump into it, with episodes from a few priority podcasts floating to the top. (Overcast pro tip: Did you know you can edit a playlist so that it automatically adds episodes of any podcast you select? And you can pick a subset from that list to be prioritized so that new episodes automatically appear at the top of the list?)
Now, with Overcast 3, I have a different approach. I now have two playlists. One, called Priority Playlist, basically functions as my play queue. That’s the stuff I will definitely listen to if I have the time, ordered in a way to keep me happy. A few of my must-listen podcasts add their episodes to this playlist automatically, but most don’t.
The second playlist is called All Episodes, and as the name would imply, it shows every podcast episode from every podcast I subscribe to, with the newest episodes at the top. From this list, I can scroll to see what’s new and if anything pops up as an immediate must-listen. When I find such an episode, I tap once to reveal Overcast 3’s new episode-action strip, tap the Add icon, and then tap “Add to Priority Playlist” or, if I’m really excited, “Play Next.” (The Play Next button adds the episode right below the currently playing episode; otherwise the episode gets dropped to the bottom of the playlist.)
Is this the most efficient way of triaging podcasts? Probably not. But it’s been working for me for the last few weeks. Unfortunately, as a work-from-home person, I don’t have as much time to listen to podcasts as I used to. This approach allows me to get my must-listens in, and then provide a menu of other stuff that I can add as time allows.
Jason Snell for Macworld
February 23, 2017 7:20 AM PT
The future of iOS is bright. While I love my Mac and expect to be using the Mac for a long time yet, iOS is the Apple operating system for the next 30 years. As I described last week, there are many different directions iOS can go in, taking the platform beyond the size and shape of today’s iPhone, iPad, Apple TV, and Apple Watch.
I believe that iOS’s future is big-and I mean that literally. The 12.9-inch iPad Pro I’m using to write this article is currently the largest iOS device in existence, but it seems inevitable that Apple will want to size up iOS even more, whether it’s in a 15- or 17-inch mega-tablet, or an even larger desktop iOS device similar to the style of Microsoft’s Surface Studio.
The problem is that iOS was originally designed for small phone screens. Even now, seven years after the debut of the iPad, there are areas of the iPad interface that feel barren. (Spaced-out apps on the home screen, I’m looking at you.)
February 23, 2017 • 43 minutes
A smorgasbord this week, as we discuss news of Alto’s Odyssey, rumors about new iPads and iPhone SE capacities, and Lex’s strange goals for his smart bulbs. We also discuss the problems with Uber, Alexa’s problems with drink recipes, and The Verge’s lack of problems with an overblown HDMI switcher.
February 22, 2017 • 29 minutes
By Dan Moren
February 22, 2017 5:28 AM PT
So it’s not “the Spaceship” after all. Apple has announced that its new, 175-acre campus will be dubbed “Apple Park”, with employees starting to transfer over in April. Moving all 12,000 employees will apparently take around six months, and during that time construction on both the building and the surrounding green spaces (which include two miles of running paths, an orchard, a meadow, and a pond) will continue.
The company also said that the 1000-seat on-campus auditorium, which sits on a hill, will be dubbed the “Steve Jobs Theater” to honor the late co-founder, who would have turned 62 at the end of this week.
And, of course, Apple continues its environmental commitment by powering its new campus on 100-percent renewable energy, including 17 megawatts of roof-mounted solar panels.
Looking for an opportunity to visit? Good news: there will be a visitor center with an Apple Store and cafe open to the public!
By Jason Snell
February 21, 2017 4:53 PM PT
This story starts, as most modern horror stories do, with a text message from Lex Friedman.
I want you to publish a tutorial on how I can use IFTTT applets and a calendar to tell my front lights to change colors depending on the date. So they’re green on St. Patrick’s Day, red on Valentine’s Day, etc.
Leaving aside the big question—what color would Presidents Day be?—my initial response was that this would be easy to accomplish. You’d think so, right? But it’s not. And the difficulty I had trying to figure out how to answer Lex’s question says a lot about just how primitive home-automation technology still is.
Sure, you can now tell Ensign Alexa that there’s a Romulan attack underway, but as Dan found out while working on that project, it’s difficult to wire up smart-home tasks that aren’t much more complex than cause and effect.
In the end, I figured out two possible solutions to Lex’s problem. Neither of them are ideal, and I’m hoping that some savvy Six Colors reader will offer an even more efficient solution. But the two approaches I took do work, with some caveats.
The “simple” approach: Multiple IFTTT applets
The easiest and cheapest approach here is for Lex to use multiple triggers on IFTTT. As I’ve complained about on more than one occasion, IFTTT is a useful but frustrating surface, because it’s incapable of anything but the simplest of cause-and-effect relationships.
That means in order for this system to work, Lex would need to create a whole bunch of separate IFTTT applets—one for every holiday he wants to monitor, as well as a handful more for regular operation.
If you’re like Lex (and me-), you like for your lights to turn on a while before dawn and turn off at sunrise, and turn on at sunset and stay on until some point late in the evening. To do all that via IFTT, you’ll need four separate applets. Two are time-based—at 6 a.m. turn on the front lights, and at 11 p.m. turn off the front lights. The other two use IFTTT’s Weather Underground source to trigger based on sunrise (turn them off) and sunset (turn them back on). For my approach below to work, make sure that these actions are setting the color of the bulb to your normal, non-holiday color.
But now we have to add holidays to the mix. First, Lex will need to create a Google Calendar for the holidays on which he wishes to bestow Geek Nation’s highest honor—the colored Wi-Fi light bulb. Since he’s got two separate periods where the lights are on, he’ll need to create twice as many events in the calendar. Since IFTTT is too stupid to trigger based on two separate factors—i.e., “if my Google Calendar says it’s Presidents Day, do this at 5 p.m.”—Lex will need to create events in both the morning and the evening of every holiday. (For holidays that repeat on a regular schedule, you can set those events to repeat annually and your work is done!)
Be sure to set these times so that they trigger after your regular daily applets, or the color change will be overridden. If your lights come on at 6 a.m., set these events for 6:15 or 6:30. If they come on at sunset, choose a time a little later than local sunset. (Yes, this means your triggers will be fighting each other out. It’s dumb, but the only other option I’ve thought of is to create an additional Google Calendar event on the morning of the next day after each holiday, setting the colors back. That seems even dumber to me.)
Next, create a series of IFTTT applets that are based on the Google Calendar trigger. Choose the trigger type “Event from search starts,” which fires off when an event with a specific keyword or phrase begins on a Google Calendar you specify, such as Presidents Day. Next, choose your light bulb of choice, and tell them to use a specific Presidents Day color. If you’re using Hue bulbs, use the “change color” action, which will also turn on your bulbs. You will need to do this for every single holiday you want to honor, with its own colors.
(If you’re using LIFX bulbs, you can change the color of the bulbs without turning them on. You could combine this approach with a daily command in the middle of the night that sets your bulbs back to the everyday color, then set the Google Calendar holiday events for slightly later in the early morning, and your regular turn-on/turn-off regimen would be undisturbed. Unfortunately, Hue’s “change color” IFTTT action also turns on the bulbs.)
Anyway, if Lex does all of this, it should work. I didn’t say it was easy or good, but…
The harder way: Zapier
I also built a version of this system using Zapier, a web app that lets you create fairly complex interactions between different web services. (If only Zapier attached to smart home stuff itself!)
I created a new app (which Zapier calls “Zaps”) to be triggered by a separate service, and set up a trigger on IFTTT to connect to the Zapier app’s URL every day right after the turn-on times for my lights.
The Zapier app, thus awakened, searches my holiday Google Calendar for the presence of a holiday on the current date. (This approach means my holiday calendar doesn’t need any times, just all-day events with the names of the holidays, preceded by “Holiday:”.) If it finds an event, it filters out the “Holiday:” part of the string, encodes the name of the holiday, and embeds it in a URL that leads back to IFTTT.
Then back on IFTTT, I create a series of applets, all triggered by IFTTT’s Maker channel, an all-purpose trigger that runs whenever anyone accesses a specific URL with a keyword you define. In this case, the keyword is the name of the holiday in question—and each applet is set to look for a specific holiday and turn on my lights with the appropriate color.
Since I have a paid Zapier account, I was able to add all of that text filtering, but this approach should work with a free Zapier account if you named the holidays in your Google Calendar things with URL-safe text that contained both a string that was consistent across all events and another that was unique to the holiday in question. For example, “holidaypresident” or “holidaystpatricks”. That string would be kicked back to the IFTTT Maker channel, and you could use that as the trigger to change the color of your bulbs, just as in the earlier approach.
Ugh ugh ugh
In short: This stuff can be done, but it’s way too complicated. A web service with a little bit of flexibility could handle this in short order:
- When it’s time to turn on the lights
- Check my calendar to see if it’s a holiday
- If it is, set a variable based on what holiday it is - “red” for Valentine’s Day, “green” for St. Patrick’s Day, and so on.
- If it isn’t, set the variable to white.
- Turn on my lights with their color set to the contents of the variable.
That’s not complicated logic, but it seems like it’s logic that’s beyond the tools we currently have access to for things like home automation.
Anyway, Lex, I hope this helps. Everyone drive over to Lex’s house on St. Patrick’s Day and see if the lights on his front porch are green.
Dan Moren for Macworld
February 17, 2017 5:37 AM PT
It’s time for the latest rumors about the Apple TV—the set-top box that we love to be “meh” about. A report from Bloomberg suggests that Apple is at work on a new revision of the device, which will bring support for 4K (Ultra High Definition or UHD) video as well as a feature with “more vivid colors,” which is probably something related to High Dynamic Range (HDR).
But is this too little too late for the Apple TV? While the set-top box probably does fine by Apple’s standards, it’s hardly the kind of category-defining product that we’ve seen even the Apple Watch or iPad be, much less aspiring to the heights of the iPhone. Historically, Apple’s TV attempts have always been a bit on the lackluster side, and these latest rumors don’t do much to change that perception.
Jason Snell for Macworld
February 16, 2017 10:30 AM PT
What is now known as iOS first debuted as iPhone Software 1.0 almost 10 years ago. Given how huge the iPhone has become over the past decade, it’s pretty fun to go back to the way Apple explained the software that drove the iPhone way back then.
“It runs Mac OS X,” we wrote (and put on the cover!) at Macworld. Apple was showing that the iPhone was a real computer at its core, with the same underpinnings that ran the Mac. Of course, we know now that Apple’s two primary operating systems are pretty different, though they share a common core.
In the intervening years, iOS-as it was renamed when it became clear that this platform was going to extend beyond the iPhone-has grown and expanded. If we define the iOS family broadly, Apple currently sells five different classes of device with iOS inside: iPhones (and the iPod touch), iPads, the fourth-generation Apple TV (tvOS is a variant of iOS), Apple Watch (watchOS, likewise), and MacBook Pro with Touch Bar (the software that runs the Touch Bar is derived from iOS and watchOS).
It got me thinking: What will Apple’s next devices be that run iOS, or a derivation thereof?
February 16, 2017 • 42 minutes
This week, John and Dan try desperately to keep the show afloat while Lex spends the whole time playing Stagehand. (I kid! Well, mostly!) But we still find time to talk about Apple’s reality show endeavors (needs more lava), the possibility of wireless charging in the next iPhone (needs more distance), and Rogue Amoeba’s experiments with selling one of its apps (needs less Mac App Store).
By Dan Moren
February 16, 2017 6:12 AM PT
Well…didn’t see that one coming. Apple’s announced that the 2017 incarnation of its Worldwide Developers Conference will be held from June 5 through June 9, but not in its usual home at the Moscone Center in San Francisco. Instead, the event will take place at the McEnery Convention Center in San Jose, about an hour south of the city.
(Fun fact: This is actually a homecoming of sorts, since the event was held in San Jose at McEnery from 1989 up through 2003.)
I suspect a large part of the move is that McEnery is much bigger than Moscone; in 2011, the center added an additional 125,000 square feet, bringing it to around 550,000 square feet. Moscone West is, all in, just shy of 300,000 square feet. That has capped the number of attendees that Apple can admit to far fewer than apply to attend—last year the company had to use the Bill Graham Civic Auditorium in San Francisco to accommodate everybody for the keynote. Update: Over at Daring Fireball, John Gruber talked to Apple’s Phil Schiller about the move, and Schiller says the number of attendees will be “about the same”, though the proximity to Apple’s headquarters will mean way more availability of the company’s employees.
Since the introduction of the iPhone, the event has become more and more popular, necessitating Apple to handle ticket sales by randomization. While the company will still be deciding registration by lottery, it seems likely that the new venue will be able to accommodate more folks.
There’s also the added fact that it’s not cheap to stay in San Francisco: hotel rates have risen considerably over the last few years, making it an expensive proposition for most—especially small developers. It’s unclear if demand will push up the prices in San Jose in the same way, but it’s hard to imagine that it’ll be as pricey as San Francisco.
It will be interesting to see how the conference will react to the new venue. There are a lot of established patterns and events around WWDC, and those will either now need to react by relocating to San Jose, or by asking folks to make the trip back and forth.
Tickets for WWDC go on sale on March 27 at 10 am Pacific. You’ll need to be a registered member of Apple’s developer program or developer enterprise program to purchase one.
By Jason Snell
February 14, 2017 8:34 AM PT
I joined Twitter because of Twitterrific.
When The Iconfactory released its first version of Twitterrific for Mac, I downloaded it, signed up for Twitter, and off I went. Ten years later, my view of Twitter as a service is still largely framed by apps, rather than the web. If Twitter was only on the Web, I think I’d use it about as often as Facebook, which is to say, not often.
I still use (and love) Twitterrific for iOS, but on the Mac I’ve had to abandon it. There hasn’t been a substantial update since 2013, and Twitter the service has moved on since then. The Iconfactory made the business decision to focus on the iOS edition, and I don’t blame them. I would’ve done the same.
Still, at least once a week I wish that I could use Twitterrific on the Mac. And now, if enough Mac users feel the same, I might get the chance. The Iconfactory has launched a Kickstarter campaign for Twitterrific for Mac, with a $75,000 goal to do a new version of the app. A $15 pledge gets you the final version, a $30 pledge gets you on the beta, and there are a bunch of goodies, too.
I’m in. Here’s hoping a few thousand of my fellow Mac users will be interested in making the up-front commitment. I’d really like to use Twitterrific on my Mac again. After all, it’s where I started.