Unapologetic

It's a little late coming down the pipe, but today the update to my LCP guide finally landed on MacStories. Now with over 26,000 words (▼)(▲)Up from 18,000 previously, although much of that original text was also cut due to changes in LCP 2.3 and 2.3.1. the guide is packed with new content.

2.3 and 2.3.1 make building advanced actions in Launch Center Pro massively simpler and easier (as well as adding many more awesome new features), so if you've ever been interested in the app and were put off by the complexity of the actions, you might try checking it out again and taking a look at my updated guide for help learning the ins and outs.

You can find the guide on MacStories.

Today marks the release of Launch Center Pro 2.3, a huge update to one of my favorite apps. This update is not a big visual change like LCP 2.0 was, but instead focuses on making significant improvements under the hood and adding new features. With 2.3, Contrast has revamped the LCP URL handler, making huge leaps in stability and usability with nested input tags, a new list builder tool, and an encoding helper overhaul. Tacking on powerful new features such as IFTTT and Giphy integration, the [action] and [contact] tags, direct links to Dropbox files, location triggers and the awesome new LC Callback actions, Launch Center Pro 2.3 marks another new chapter in iOS automation.

I had a few thousand words written on the update and almost ready to post for this article, but seeing Eric Pramono's post on this subject, he seems to have already taken care of that for me. I'll save my words for the update to my Launch a Center Pro guide on MacStories, which you should look for some time next week.

In the mean time, if you're curious about the new features available in LCP 2.3, check out Eric's post (linked above) as well as Federico Viticci's post on MacStories.

Via The Verge:

“We primarily use the Gotham font family: elegant and direct, stylish but not exclusive,” Twitter explained. “Putting well-designed words in our product enhances the user experience.”

I'm a huge fan of the Gotham font family (not including Gotham Rounded, which looks a bit too childish for my tastes). In fact, this very paragraph (and every paragraph here on Unapologetic) is displayed in Gotham.

There's some pushback, as with any big design change to a popular platform, but I'm a fan of this move.

I've had a busy last couple of weeks. Catching up on some news I missed, Kara Swisher had a fantastic article on Katie Cotton and the sexism in the tech industry:

That kind of hard driving is part and parcel to the business, even if she was harder driving and, because of that, more successful than most. As she once told me when we talked about her outsize reputation in the tech press: “I am not here to make friends with reporters, I am here to put a light on and sell Apple products.”

It was no surprise that some used the opportunity of her exit to drag out their complaints in the kind of strange rage that has been — at least to my mind — oddly emotional and sometimes full of vitriol that would never be directed at a man who was similarly strong.

[...]

I only dwell on this because it’s both sad and disturbing that it’s still okay to talk about a high-ranking woman in this way and make it seem as if it was a cogent and valid commentary on her performance as a professional executive.

I meant to post this shortly after my article on App Links last week but college finals distracted me, so here it is now.

I've seen some people suggesting that the adoption of App Links could lead to x-callback-url fading into obsolescence. This is a completely unfounded notion. Even though App Links and x-callback-url are both URL scheme-based methods of providing deeper and more powerful inter-app communication, they generally will not compete because x-callback-url provide's only a subset of App Links' functionality. It's true that the referer_app_link property of the App Links protocol provides a functionality practically identical to that provided by x-callback-url, but that functionality is bound by the rigidity of the rest of the protocol while x-callback-url is completely free from such constraints. In order for App Links to become some sort of standard for navigation, they have to strictly define the parameters possible for the first action that tapping an App Link will launch. This first action must draw data from an actual source on the web, and it must find a very specific set of instructions in that data. x-callback-url, on the other hand, has absolutely no restrictions on the first action which its x-success parameter is tied to. This distinction makes x-callback-url more versatile, but without the strict guidelines for finding information from the web to use in the first action, it could never do what App Links does on its own. App Links, on the other hand, could never be used for such a wide variety of actions for iOS automation like x-callback-url can be used for, because the referer_app_link property can only be used to return from navigating to some other place, and can only be defined once for each page of the navigating app. There is no way to use different referer_app_links depending on what link is tapped, so the secondary action is not limitless like x-callback-url actions are.

There are a few exceptions in which x-callback-url is being used in place of App Links, most notably in Google’s suite of apps. When you tap a YouTube link in Chrome, or vice versa, you will jump to the other app with a special back button to return you to the original one when you’re finished. Google can only do this, however, because they control all of the apps that the feature works with, and it is a fairly small list of apps. They basically built their own version of App Links, but it could never be used as an overarching protocol like App Links because Google’s developers had to manually build support for each app it works for into all the other apps. Greg Pierce, the creator of x-callback-url, has implemented similar inter-app communication between some of his apps, but again this can only be done because he built all the apps and has full control of all the code. App Links will work for any app without developers having to manually add support for each and every App Link-able app into their own code, that’s the entire point of the protocol.

These general distinctions are what have led x-callback-url to be used mainly to increase productivity by tying together powerful and usually user-customized actions. App Links, on the other hand, will remain geared simply towards improving navigation, and will never become nearly as great a productivity tool as x-callback-url. Thus, while in some cases they may get in each other's way, for the most part these two protocols will live in harmony, neither eliminating the other.

Slingshot is a new app by Squirrels, the guys behind AirParrot and Reflector. It's a cross platform wireless screen sharing and video chatting app, and it looks great.

I use Reflector for all of my iOS screen recording videos. It's polished, simple, and fits my needs exactly. The wireless aspect is awesome too, using AirPlay screen mirroring to remove the need for plugging my device into a computer. I'm assuming the mirroring in Slingshot works the same way. If this is the kind of thing you're looking for, I would definitely check this app out.

At its f8 developer conference earlier this week, Facebook announced App Links, a new open source protocol to allow developers to deep-link to mobile apps from web browser environments. From the App Links website:

Right now, linking on mobile is a lot more frustrating and complicated than it is on the web. There isn’t an easy, consistent way to control what happens when someone clicks on your content in mobile, which makes it difficult to provide the best experience for your users. It’s also hard to find out when—and how—to send people out of your app and directly into another.

We built App Links to help with that. It’s an open, cross-platform solution for app-to-app linking that gives you the tools you need to expose deep links in your app or to link out to others.

The idea of deep-linking to apps arises from the fact that many native apps have significantly better experiences than their web versions when being viewed on the smaller screens of mobile devices. Take Dropbox for instance. The Dropbox mobile app provides an excellent experience for viewing Dropbox content on iPhones or iPads. Accessing your Dropbox files on the web through Safari or another web browser is possible, but it is nowhere near as polished of an experience. The issue here is that anytime you tap a Dropbox link on your device, it is not smart enough to do anything except launch the Dropbox website in the nearest web browser. Even though you have a perfectly good Dropbox mobile app ready to give you exactly what you want in an environment built for your specific device, you're forced to use the lesser experience of the web view.

App Links is an attempt to fix this problem. If you tap a Dropbox link in an app that supports App Links, it will figure out that you have the Dropbox app installed on your device and redesign the link as a Dropbox.app link instead of a Dropbox.com link. Then when it opens the link you will launch into the Dropbox app to view the content in question instead of seeing it in a web browser. This is known as “deep linking” because that content is “deep” inside of the Dropbox app. (Really it's all on the web, because that's where the Dropbox app gets its data, but the point is that this content is not accessible through the top level hierarchy of the Dropbox app. It's not easily found unless you search “deep” inside of the app, so linking to that content is “deep linking”.)

This idea may seem foreign, but we actually deal with it every day on the web. Basically every URL is a “deep link” to some sort of content on the web. Every article that you follow a URL to get to was buried somewhere deep in that website's hierarchy, but that URL was able to link you directly to it. This is an extremely powerful concept which has been so mastered on the open web that we don't even refer to it as deep linking there, it's just linking. In the mobile app ecosystem, however, deep links are still struggling to find mainstream support from developers. We take it completely for granted that every single piece of content on the web is accessible from a link, but in most mobile apps, content is only accessible by navigating your way through the app's hierarchy until you get to the location of the content you're searching for. Imagine if every time you wanted to go to an article on a webpage you had to go to the website's home page, navigate to the section the article is in, then scroll through other articles until you found it. The notion of navigating websites in that manner, without direct, deep-link URLs, is ridiculous.

The problem with native apps, the main reason why deep links did not become as ubiquitous as they are on the web, is that unlike websites, apps are not always accessible. A native app link can only work if the app it corresponds to is installed on the device, and most developers cannot be very certain that their app will be installed on any given device. (▼)(▲)A notable exception to this rule is Facebook. If you take any given iOS device, the likelihood that the Facebook app is installed on it is probably higher than almost any other app besides Apple's own. App Links seeks to solve this by creating an open source protocol which developers can implement to identify whether an app is installed, then change web links so that they will launch into the corresponding apps instead of the standard web views. These won't just be basic app launching URLs, but true deep links to send you to the exact content you want to see, just in an app instead of a web view. Tap a Facebook link and see the result in the Facebook app. Tap a Spotify link and start listening to the song in the Spotify app. Facebook has launched app links with quite a few big name supporters already, including the aforementioned Dropbox and Spotify as well as Hulu, Pinterest, GoodReads, Redfin, and several others. Of these, however, the only ones which will actually be implementing App Links at this time are Facebook, Mailbox (which is owned by Dropbox), Quip, and Spotify. The rest will simply be publishing App Link metadata (More on what that means later). In other words, while links in the apps from the full list of supporters will have the capability of being changed from web links to app links, only when you click those links from one of the four apps that have implemented App Links will they actually send you to the app instead of the web.

App Links are a great idea, inspired by real problems with iOS (▼)(▲)App Links support other major platforms too, but I'm focusing on the App Links implementation in iOS for this article., but there are a lot of concerns with this type of protocol as well. In this article I'll try to explain some of the problems, as well as the advantages, that may soon be associated with App Links. First though, you need to understand exactly how App Links work, and the difference between publishing App Link metadata and actually implementing the protocol.

How App Links Work

As I've written about before, basically the only way for apps to communicate on iOS is through URL schemes. (▼)(▲)There is also the “Open in...” menu, but that's mainly just for transferring documents between apps. These work just like website URLs do, providing a simple “domain name” which, when called, will launch you out of your current app and into the app associated with that name. These URLs follow the basic syntax of yourapp://, where “yourapp” is whatever title a developer has registered his or her app to. Developers have the option to register their apps to a URL scheme, but unlike with website domain names, they don't have to. Similar to website URLs though, developers can build their schemes deeper so that adding more data after the :// can direct users to places further within the app, or even launch actions inside of it. These schemes are the foundation on which App Links are built. Apps which support App Links will likely have complex URL schemes to allow “deep linking”, creating specific links for every piece of content accessible through the app so that a particular URL action can launch users directly to a specific item of content “deep” within the app.

Two things have to be true for you to click a link and have it open in an app instead of a web view. First, the app you are clicking the link from has to have built in support for App Links, and second, the publisher of the link you are clicking has to have included App Link specific metadata in the HTML of that link's webpage. This is the distinction between being an App Link “publisher” and having actually implemented the App Links navigation protocol. This is also the biggest disadvantage App Links is going to face in gaining any traction. App Links can only work if you are clicking on a link which has App Link metadata and the app in which you are clicking said link has implemented the App Link navigation protocol.

So how exactly do publishers include App Link metadata? That part is extremely simple. Within the HTML <head> tags of each webpage, publishers must simply include a few extra lines of code which hold the data App Links needs to function. Each line of code will look something like this:

<meta property="al:DEVICE-TYPE:PROPERTY-TYPE" content="DATA" />

For each item, “DEVICE-TYPE” will either be ios, iphone, or ipad. “PROPERTY-TYPE” will then either be url, app_store_id, or app_name. Finally, “DATA” will be the piece of data associated with the property type. Within each line of metadata, publishers can choose to add code for any or all device types, depending on how many manifestations of their app there are. If the app is universal, they only need to provide metadata for the device type ios. If their app is iPhone or iPad only, they can choose for themselves whether they want to use ios anyway, or use iphone or ipad depending on which platform their app is on. If there are separate versions of their app for iPad and for iPhone, then they can include metadata for both the iphone and the ipad device types. As for properties, the url property will include the URL action to launch to the specific piece of content within the corresponding app. The url property is also the only required property, everything else is optional. Next, the app_store_id property will include, not surprisingly, the app's specific App Store identification number. Finally, the app_name property will include the name of the app. The last property that most content publishers will want to include is the al:web:url property. This is that actual web URL for the page, and in fact probably the same URL as the one the user clicked to get to the App Link metadata. There is also the option to include an al:web:should_fallback metadata line which can be set to false if there is no web version of your content, or in other words if you have only an app but not a website. This is possible because Facebook itself, as well as a company known as Parse, are providing services to publish App Link metadata without actually having any web content. In that case, a publisher could post a link which directs to a Facebook or Parse webpage which simply holds the metadata and nothing else. To the user, they would tap the link and open straight to the app without ever seeing that there was no web version.

So that's how publishers can start adding App Link metadata to their webpages. If the explanation may have seemed complicated, the actual implementation is really just a few lines of simple and repetitive code, which to anyone who knows how to write HTML will be extremely easy.

Simply having publishers include App Link metadata in their webpages isn't all that App Links requires. It also necessitates that the app in which an App Link is being clicked haas implemented the App Links navigation protocol. This protocol describes a few extra steps between a user tapping a URL and that URL being opened. First, a request for any metadata beginning with al wil be sent to the target URL. If any metadata is retrieved, meaning that webpage has published data for App Links, then the navigating app will next search through the returned metadata looking for device types of the same type that the current device is (i.e., if you're tapping a link on an iPhone it will search for any metadata beginning with al:iphone, but if you're tapping on an iPad it will search for al:ipad). If it doesn't find metadata for the device, it will search again for metadata containing al:ios. If that's not found either, it will check whether al:web:should_fallback has been set to false. If it has been, the navigation will fail and nothing will happen. If al:web:should_fallback has not been set to false, the URL will be opened regularly in a web view. However, if it does find any metadata either associated with the proper device type or containing al:ios, it will proceed to construct a new URL to launch instead of the one being tapped. This is a process as well. First, the navigating app will check whether the URL defined by the url property of the App Link metadata can be opened on iOS. Assuming the publisher did not have a typo in their URL action, the only reason this would fail is if the app is not installed on the device. If the URL does not fail, meaning the app is installed, it will launch the URL and send the user into the native iOS app corresponding to the link, and to the proper place within the app. However, if the URL does fail, hopefully meaning the app is just not installed, not that the published URL has an error, then the app_store_id property can be used to open the iOS App Store to the page for the uninstalled app in question.

Since all of this goes on in the background, to the user there are only a few possible outcomes if they tap a link which has some sort of App Link metadata in its markup:

• If the app is installed on the user's device, open the content from the link inside of the app.

• If the app is not installed on the user's device, open the App Store to the app's download page.

• If there is no App Link metadata associated with the user's platform (e.g., the publisher included App Link metadata for only the Android operating system but not iOS), open the URL regularly.

• If there is no App Link metadata associated with the user's platform and there is no web version of the content (e.g., the App Link is for an Android only app which does not have an accompanying web component), do nothing.

There are two other properties defined in the App Links navigation protocol, but rather than metadata properties defined in the link that is being navigated to, these properties are defined by the app doing the actual navigating. That is, the app from which a user is opening an App Link. The first of these properties is the al_applink_data property. This is a property which is sent as part of the URL action to the app being launched by an App Link, and it simply contains context for the navigation. That is, this property contains the target URL that was initially being navigated to before the App Link took over, the app token of the navigating app, the version number of the App Link protocol being used, and the identifying string for the library that the navigating code is using to navigate. Presumably, an app being launched by an App Link can choose to make use of this contextual information or just ignore it. In the future it will become significantly more useful when more version of the App Links navigation protocol exist. In that case, if an older app which has not been updated is the sender of the App Link, the receiver app can identify the fact that the sender is using an old version of the protocol and adjust accordingly.

The second property which the navigating app can send in the URL action is called referer_app_link, and this one is much more interesting than al_applink_data. referer_app_link provides a URL to return to the navigator app after the user is finished with the content they navigated to in the reciever app. The developer of the reciever app can choose to look out for the referer_app_link property and then implement a back button into their interface. That way when the user wants to return to the app from which they tapped the App Link, they can just tap the back button to automatically jump back to the app they had navigated from.

Advantages of App Links

With App Links, Facebook imagines, and is hoping to begin to create, a world in which low quality web versions of apps no longer need to be dealt with. Imagine if every time you tapped on a link to a tweet (even outside of Twitter apps) your device could open that tweet in the official Twitter app instead of the terrible Twitter web app. Not only would you be viewing the tweet in a better environment, but you would already be logged in and free to reply, retweet, favorite or any other action, which is often a huge pain to try to do in Twitter for the web on an iOS device. Not only that, but when you finish with the tweet, a button will be waiting for you to tap to go straight back to whatever app you had been in before. This would work the same way with any app, saving you time and annoyance by never again forcing you to use the web version of Dropbox, Spotify, Facebook itself and more.

This could be the first step to the inter-app communication that many of us nerds have been dreaming of since we saw the capabilities of x-callback-url. Best of all, average users, those who have little knowledge or interest in what's happening under the hood of their devices, could make use of these new capabilities without ever needing to “install an action” or change their habits in any way. They would simply get a better overall experience on their devices.

Difficulty Getting Adoption

By far the biggest hurdle that App Links will face is getting wide adoption. Unfortunately, the likelihood of App Links ever becoming a complete standard is fairly low, because it's highly doubtful that Apple would ever implement App Links, a third party protocol, into Mobile Safari. In other words, App Links will very likely never work in the most popular web browser available on iOS. This leaves it to try to scrape up the leftovers: web browsers built into third party apps such as Twitter or email clients (Mailbox has already committed to supporting App Links), as well as full-on third party web browsers like Chrome or iCab Mobile.

Without finding its way into Mobile Safari, App Links has a steep uphill path to reaching mainstream support. The only way I could see Apple ever implementing the protocol is if it manages to become a true standard among third party web browsing experiences and Mobile Safari is falling behind without it. Yet still, it seems more Apple-like to just build their own protocol into iOS than to implement one built by Facebook, particularly when you think about some of the possible issues that could arise from people abusing the App Links protocol.

Concerns With App Links

The reason Apple has not implemented powerful inter-app communication up until now is because it is a danger to security. By keeping every app in its own sandboxed environment, it's very difficult for apps to do something in the background without the user's knowledge. URL schemes are the only method of inter-app communication that is not fully controlled by Apple. That lack of control does mean that running URL actions is a security risk. Once you launch an action, it's likely impossible to stop it from fulfilling its function unless it is a long chain that bounces between different apps. With the current state of iOS automation, this has provided very little danger because the users are completely in charge of which action they install and run. Furthermore, it's a field predominantly populated by people who are more advanced users of iOS, and likely to realize if an action they've installed has done something other than what its description had said it would do.

Security issues related to URL schemes are in no way going to be some sort of malware. iOS is still sandboxed, and running a URL action can't install any malicious apps from outside the App Store or anything like that. URL actions can become dangerous, however, when they send you somewhere unexpected. As far as I can see from the information on the App Links protocol that Facebook has published, the protocol does not include any sort of check to make sure the App Link it is navigating to is actually going to the content it should be. Of course, there's really no way for the protocol to do something like this because it can't read the content it sends the user to, it can only launch the action defined in the metadata of the webpage it scrapes. Without a system of checks, I can think of a few different, and all seemingly easy ways in which the system could be abused to take advantage of unsuspecting users. (▼)(▲)I only know as much as what was written in the documentation, so it's possible that App Links does have some sort of built in features under the hood which would try to prevent the following situations. If you're aware of something like that, please contact me about it so I can update this post.

First, App Links could provide a way for advertisers to get more users to download their apps by paying websites to use app_store_id properties for the advertiser's app instead of their own. This way, if the URL provided by the App Link failed to launch, meaning the user did not have the app of the link's publisher installed, the fallback could send the user to the App Store to download an app which is not the app associated with the link, but rather some random game or another app which an advertiser has paid the App Link publisher to link to. Sure, the publisher might get less downloads of their app, but I can't imagine that advertisers won't be able to find a price that will convince some publishers to forsake a few downloads of their apps. Particularly when you recall that Mobile Safari will not work with the link, so the majority of users navigating to it will not be sent to the wrong place.

Next, just as the app_store_id property is not, nor likely could be checked by the App Link protocol, neither is the url property, nor the web:url property. Either of these could be tweaked to send the user to a different website than the link they actually tapped would have taken them to. Users could tap a link and unsuspectingly be redirected to porn or other explicit material on the web. They could even be directed to phishing websites. It's all the same problems that everyone who uses the web constantly faces, but now the links can be hidden another layer down and you may never actually tap the link you end up being directed to. Just like with the App Store links, all of this nefarious redirecting will cause the actual website of the link to lose hits because the user never reaches it, but advertisers or other organizations would surely pay them for their troubles.

The final concern I have with App Links is less tied to malicious uses of the protocol. Rather, it's simply the annoyance that will inevitably come from tapping a link and being redirected to the App Store download page for the website's app instead of seeing the content you were looking for. This is even worse than the infuriating tendency of many websites to throw popups on top of their content informing you that they have an app in the store, because now they can actually throw you out of your app instead of just asking with a popup.

Conclusion

All things considered, App Links seem to be more trouble than they're worth. I like the idea of the future that Facebook is pushing for, but with rumors of better inter-app communication coming in iOS 8 or 8.1, I can only hope that Apple reveals a way to do this without the shortcomings of Facebook's implementation. Even if they don't, I might actually prefer having to use lower quality web versions of native apps sometimes as long as they promptly and predictably get me to the information I want. With App Links, each link could do one of three or four different things, and the inconsistency with that makes me shy away from fully supporting the idea. At least with standard links there are no surprises: you tap the link, it opens in a web browser.

That said, Facebook is definitely pushing in a direction that I want to see iOS go. If there were a more foolproof way for links to know to open apps instead of web views, I would support it completely. The idea of always being able to use the higher quality native app experiences of internet content is an amazing one. I just don't think we're ready for that yet, and when we are it may need to come as a first party API, not a third party protocol.

New features include lane guidance, offline maps, Uber integration, and voice search. MacStories has great coverage of the new features, so I won't bother rehashing all of them here (headline link).

The features of this update push Google Maps ahead of Apple's offering in new ways. Apple has been doing a great job at improving the reliability of Apple Maps, but they've spent so much energy on improving that aspect that their app has gained few new features since its release with iOS 6 nearly two years ago. 9to5Mac has reported that transit support is in the works for iOS 8 or 8.1, which will be a great help, but I hope we see even more improvements and new features such as offline maps as well.

Max Temkin writes up the hilarious story of how he and his team at Cards Against Humanity pulled off one of the most elaborate pranks I've ever heard of.

PWNMEAL Extreme Gaming Oatmeal was a prank that Cards Against Humanity played at PAX East 2014. We created a fake “extreme oatmeal” brand and distributed sixty thousand packets of instant oatmeal with Cards Against Humanity cards inside to attendees of PAX.

Follow the headline link to find the whole article. Great read.

The Verge has an excellent profile of the new Snapchat 7.0 update, including quotes from an interview they did with Snapchat founder Evan Spiegel.

The update is the biggest since Snapchat's inception, adding both text chat and video calling capabilities, but Snapchat has implemented both of these in an innovative, unconventional manner.

The whole article is excellent, but here are a few of my favorite excerpts:

To Spiegel, the reason none of his friends video call each other on a daily basis is because “calling” was born of an era where software needed to emulate real-world tools. “What does a phone look like without a ringer?” he asks. Skeuomorphic metaphors have always been a part of computing, Spiegel says, because that’s how we all learned to use computers. “But,” he says, “the biggest constraint of the next 100 years of computing is the idea of metaphors.”

[...]

He sums up his idea more neatly. “For Snapchat, the closer we can get to ‘I want to talk to you’ — that emotion of wanting to see you and then seeing you — the better and better our product and our view of the world will be.” To Spiegel, the future of communication isn’t about rethinking or upgrading phone calls as Skype, FaceTime, and Hangouts have done. It’s about imagining a future that leaves the phone metaphor behind entirely.

[...]

“We’re trying to get rid of these weird boxes that we put media into and get to the essence of conversation — that we’re both here,” says Spiegel.

If we weren't sure why Evan Spiegel turned down Facebook's $3 billion acquisition offer last year, this update and The Verge's interview make it pretty clear. Spiegel doesn't want to make boatloads of money, he wants to make a true difference in the way people communicate.

Snapchat 7.0 is the first step toward that goal, the first attempt to break free from the constraints of the “phone call” metaphor. I really like the implementations of these new features, and I'm excited to see what Snapchat does next.

I had the opportunity to join Ronnie and Scott on Pocket Sized Podcast this week. We talk about Drafts, Launch Center Pro, and iOS automation. This was my first podcast, and I think it turned out pretty well.

You can listen to the episode through the headline link.

I'm happy to have had the opportunity to write for the beautiful new redesign of MacStories 4.0. Similar to my previous article for MacStories, Automating iOS: A Comprehensive Guide to URL Schemes and Drafts Actions, this new one is an exhaustive guide for another Titan in the field of iOS automation: Launch Center Pro. Whether you're a complete beginner, or an expert on the app, my guide will bring you up to speed on Launch Center Pro's full feature set, including tips and tricks to access LCP's most advanced capabilities.

You can check out the guide on MacStories.

Nilay Patel:

And there's the entire problem. Wheeler's plan, in a nutshell, is to say that service providers can do anything they want as long as it's not “commercially unreasonable” — and that he's is in charge of deciding what's reasonable and what's not. This is regulation by muddle: Wheeler's thrown a new vague term into the mix and declared that vagueness to be power.

A hilarious yet disturbing article by Dylan Matthews on Vox regarding the true nature of otters. I had no idea otters were such terrible animals.

One example:

Sea otters murder even when it doesn't provide them with food or offspring, like straight-up sociopathic spree killers. In 2010, veterinarian Heather Harris and her coauthors Stori Oates, Michelle Staedler, Tim Tinker, David Jessup, James Harvey, and Melissa Miller published an article in Aquatic Mammals documenting about 19 cases of sea otters attacking baby seals.

[...]

You read that correctly. After raping a baby seal to death, this psycho licked his paws, like Hannibal Lecter or something.

Via Daring Fireball, Anne Broache back in 2007 on Obama's pledge to support net neutrality:

The question, selected through an online video contest, was posed via video by small-business owner and former AT&T engineer Joe Niederberger, a member of the liberal advocacy group MoveOn.org. He asked Obama: “Would you make it a priority in your first year of office to reinstate Net neutrality as the law of the land? And would you pledge to only appoint FCC commissioners that support open Internet principles like Net neutrality?”

“The answer is yes,” Obama replied. “I am a strong supporter of Net neutrality.”

Today, not only is the chairman of the FCC a former venture capitalist and lobbyist for the cable and wireless industry, but he and his agency are proposing rules which severely threaten the neutrality of the internet.

Today, the FCC announced plans to completely reverse their previous position on net neutrality. Edward Wyatt, for the New York Times:

The Federal Communications Commission will propose new rules that allow Internet service providers to offer a faster lane through which to send video and other content to consumers, as long as a content company is willing to pay for it, according to people briefed on the proposals.

The proposed rules are a complete turnaround for the F.C.C. on the subject of so-called net neutrality, the principle that Internet users should have equal ability to see any content they choose, and that no content providers should be discriminated against in providing their offerings to consumers.

[...]

Proponents of net neutrality have feared that such a framework would empower large, wealthy companies and prevent small start-ups, which might otherwise be the next Twitter or Facebook, for example, from gaining any traction in the market.

If this goes through, the consequences are immense. As consumers, we're looking at higher subscription prices as content companies try to subsidize the new fees they're paying internet service providers for faster and more reliable streaming. These payoffs will be exorbitantly high, making it nearly impossible for newcomers to slip in with lower subscription prices because they won't be able to pay for the same speeds as Netflix, Disney, and other giants. The FCC is legally allowing the ISPs to rip the content companies off, and encouraging content giants like Netflix, Disney and HBO to entrench themselves against future competitors who can't afford to buy into the internet “fast lane”. Worse, the charges for this fast lane are completely at the discretion of the ISPs, so they can charge more to one company as to another for the same service. The potential for unfairness and corruption is mind boggling.

The neutrality of the internet, which until now has been fair for every content provider, is being put in the hands of Comcast, AT&T, Verizon, and others like them. Maybe I'm wrong, but to me these don't seem like the most trustworthy companies to hand the equality of the internet over to. (▼)(▲)I'm not wrong.

I've posted Fantastical actions before, but since then some changes to the URL schemes of Fantastical and Launch Center Pro have allowed for better implementations. (▼)(▲)Fantastical has added a few new options to its URL scheme. Most notably, you can trigger a parameter to automatically parse events without you needing to press “add” each time, so after you launch the action you don't have to touch the device again until all of your events have been parsed. Another new parameter allows you to tell Fantastical that you are sending it a reminder to be parsed without manually adding “todo” before the text of the reminder. This isn't that big of a deal, since “todo” was added automatically in the old action set anyways, but it looks a little bit nicer as your reminders are parsed, and I like their attention to such small details. As for Launch Center Pro, new features have allowed for the creation of recursive actions, massively simplifying my previous Fantastical actions for LCP by removing the need for both Pythonista and Drafts to be used in the action chain. This post will detail a series of actions which will allow you to send a list of events from either Drafts or Launch Center Pro and have them be automatically parsed, one by one, in Fantastical. Unlike the last version, the Launch Center Pro actions will no longer require the use of Pythonista or Drafts, they run completely via URL scheme between LCP and Fantastical.

The Parse in Fantastical Action

The Parse In Fantastical Action takes a draft (or Launch Center Pro prompt) and sends it to Fantastical to be parsed. You can parse a single event or multiple events using the same action.

Drafts

Type your event or list of events in Drafts, then run the Parse in Fantastical action to launch the sequence.

If you want to parse a list of events, leave one completely blank line between each event in your draft. Type each event in natural language as you would if you were typing it directly into Fantastical.

Direct Import Link for the Parse In Fantastical Drafts Action

Launch Center Pro

In Launch Center Pro, first run the Parse in Fantastical action. This will bring up an input prompt in which you can type one event. Even if you need to parse multiple events, type only the first one in the prompt box. With your first event typed, hit “Launch” to run the action. You will be sent to Fantastical where the event is instantly added to your calendar, then you are automatically redirected back to LCP, without any input required. This action is recursive, so on your return to LCP, you will immediately be provided with another empty prompt box. Type your second event here and hit “Launch” to parse it and return to LCP for a third. This process will repeat until you hit “Cancel” instead of “Launch”. If you only needed to parse one event, just hit “Cancel” after it has parsed the first event and you're done. (▼)(▲)An important thing to note: recursive actions in Launch Center Pro only work by utilizing a clipboard hack, so make sure not to copy anything onto the clipboard between starting and finishing parsing your events, or you will break the action. Furthermore, make sure you don't have anything important stored only in the clipboard when you launch this action, as it will be overwritten.

Direct Import Link for the Parse In Fantastical LCP Action

The Parse Reminders in Fantastical Actions

The Parse Reminders In Fantastical Action takes a draft (or Launch Center Pro prompt) and sends it to Fantastical to be parsed as a reminder. You can parse a single reminder or multiple reminders using the same action.

Drafts

Type your reminder or list of reminders in Drafts, then run the Parse Reminders in Fantastical action to launch the sequence.

If you want to parse a list of reminders, leave one completely blank line between each reminder in your draft. Type each reminder in natural language as you would if you were typing it directly into Fantastical.

Direct Import Link for the Parse Reminders In Fantastical Drafts Action

Launch Center Pro

In Launch Center Pro, first launch the Parse Reminders in Fantastical action. This will bring up an input prompt in which you can type a single reminder. Just like the event parsing version of this action, it is recursive, so if you have multiple reminders to parse, only type one each time before hitting “Launch”. After that reminder has been parsed you will return to LCP and immediately be given the option to parse your next reminder. Whenever you are finished parsing, just hit “Cancel” instead of “Launch” to end the sequence.

Direct Import Link for the Parse Reminders In Fantastical LCP Action

The Fantastical Action Menu

If you want To conserve space in your Launch Center Pro action grid, you can combine these Fantastical actions into an “action menu”. This will be a single action which, when run, will bring up a list menu in LCP with three options: “Parse Events”, “Parse Reminders”, or “Launch Fantastical”. The first two will begin the corresponding recursive actions listed above, giving you prompt boxes to keep parsing reminders or events until you hit “Cancel”. The third option will, of course, simply launch Fantastical.

Direct Import Link for the Fantastical Action Menu

Refills, by Thoughtbot, are prepackaged patterns and components for websites, built on top of Bourbon, Bitters, and Neat. If you code websites, you need to check these out. From proper sliding menus to grid items, heroes and accordion tabs, every Refill looks incredibly well done and impressive. The list includes more than 20 commonly desired website patterns or components which are simple in idea, yet tricky to implement.

The whole thing is open source. Great resource.

Speaking of students (high schoolers now), Medium just announced a scholarship opportunity for high school seniors, and it sounds awesome.

Via the Medium blog post:

“Share your story.”

It’s what we hope everyone will do when they come to Medium. Stories make the world a better place, and we want to make a better place for everyone to write and share them.

“Share your story” also happens to be one of the most common questions offered in the dreaded college entrance essay.

Every year, thousands of college-bound high school seniors are forced to introspect on a Big Topic. Amid the predictable wall gazing, eye rolling, foot tapping, XBoxing, texting and Snapchatting, actual words are strung together in grammatically correct sentences and arranged in paragraphs with a beginning, middle and end. Thoughts are thunk. Emotions are emoted. Insights are sighted. And when all this teeming energy, confusion and angst comes frothing up as prose. It is promptly appended to an application form, sent off for bureaucratic review and dropped into permanent archival limbo.

Great stories are buried in that annual pile. We intend to find them.

All entries are first read by average Medium readers, and the top 12 as recommended by these readers will be sent to a panel of five best-selling authors to pick the three best of the best.

This isn't a horrible standardized test prompt. The topic is wide open: all you have to do is share your story. If yours is interesting and you have a good mind for writing, don't miss this chance. I certainly would have entered if it had been available last year.

This morning, Squarespace announced a new initiative to give students of particpating colleges a huge 50% off discount for their first year of service. The list of colleges seems to be pretty huge, but you can check if yours is on it by searching here. (▼)(▲)If you attend the University of Arizona, as I do, I can tell you right now that it is on the list. (Also, if you attend the same college as me, you should contact me and we should get together.)

While I don't currently use Squarespace, I used to use it for my old site, The Axx, which is still hosted there. I cannot recommend Squarespace higher. If you're in college, school responsibilities are probably going to be consuming too much of your time for you to code a website from scratch, but with Squarespace you can have a beautiful, responsive site finished and live within mere hours.

There's no better time to start your website than now, and there's no better place to start it quickly than Squarespace. Just sign up with your university email address and you'll get access to the discount.

My one disappointment on the subject is that if you already have a Squarespace website, you can't get access to the discount. I can't imagine a reason to punish users who adopted Squarespace before the discount by not letting them use it. Early adopters can be poor college students too. (▼)(▲)And “early adopters” isn't even a fair term for these users. Squarespace has been around for a long time, it should have awarded already present college users with an unexpected discount as well.

Rick Bookstaber:

You would think that in the emerging world of big data, where Amazon has gone from recommending books to predicting what your next purchase will be, we should be able to find ways to predict how well a student will do in college, and more than that, predict the colleges where he will thrive and reach his potential. Colleges have a rich database at their disposal: high school transcripts, socio-economic data such as household income and family educational background, recommendations and the extra-curricular activities of every applicant, and data on performance ex post for those who have attended. For many universities, this is a database that encompasses hundreds of thousands of students.

Last year, I had to make the decision on which college to attend. Thankfully, I had managed to get fairly high scores on my SATs, but all that did was give me the possibility of having access to most colleges, I still had to pick which ones to apply for. The only easily accessible data points I could use to make these decisions were the locations of the colleges and the strengths of their computer science programs, the latter of which varied wildly depending on which study you looked at. Basically, I applied for and chose the U of A because it was close to home and the computer science program was supposed to be pretty decent. I wasn’t set on staying in Tucson, but the convenience and the lower in-state tuition was simply easier since I didn’t have any explicit reasons to choose any other universities. While I’m not unhappy with my decision, I would not be at all surprised if I’m missing out on some college out there that would have been a much better fit for me. I have no idea if that’s true though, because the way the system is right now, the job to find which college is right is left completely up to the student. This makes no sense whatsoever. We are forcing the student to pick from hundreds of colleges, the cultures and student bodies of which they know very little about, when we could instead shift the hard work onto the colleges. Colleges know very much about their own cultures and student bodies, and they also get tons of data on every student that is applying. Why not analyze all of this data and come up with educated guesses as to which schools could be right for individual students? My decision could have been completely different if I had been presented with a list of colleges telling me that I am statistically more likely to be a good match there than I am at the U of A, or any other college. I could always ignore the list and choose what I wanted anyway, but the existence of such a tool would completely change the way I, and all students, go about picking universities.

As Bookstaber discusses in his article, this isn’t an impossible goal. While setting up a new system based on big data would certainly not be easy, and would likely take years before it reached a fully optimal level, the actual tools with which to analyze the data already exist in companies like Google, Facebook and Amazon. Wouldn’t it be nice if we could use the methods these companies have already developed for analyzing big data from millions of individuals as a way to improve our education system instead of just to serve targeted ads?

Yesterday, I was playing around with some deep nested actions and multiple levels of encoding in Launch Center Pro. The results of that were largely useless, but they did give me an idea for how to get recursive actions working in LCP, and the results of that are described in detail below. Be forewarned: this gets pretty technical. If you don't want to bother with the inner workings of the method, you can jump to the bottom and get your hands on the recursive Fantastical action via the direct import link (▼)(▲)Launch the action in LCP to be presented with a prompt box for an event that you want to be parsed in Fantastical and added to your calendar. Tap Launch and Fantastical will automatically parse and add your event, then take you back to Launch Center Pro where you are automatically presented with another prompt box for the same thing again. The loop goes on until you hit cancel on a prompt box. If you want to add multiple events to your calendar, this is the fastest, easiest way to do so..

Unlike Drafts, Launch Center Pro does not allow you to save actions by a certain name and then call that name to run the action. This would seem to render recursive actions impossible in Launch Center Pro, as we only create them in Drafts by having an action call its own name and run itself again when it completes. We can have an action cycle a handful of times by manually nesting it in its own x-success variable, but this method means that the action will only run a preset amount of times (the number of times you nest it inside itself, no more and no less), and that does not make it very versatile. Furthermore, every level of nesting requires another level of encoding, and that gets extraordinarily complex very quickly. What we want isn't a massive, incomprehensible chain, it's a small chain, with no more than a single x-success, that will loop infinitely until we cancel it. Since we can't save an action by a name and then call it, there's only one other way: variables. Unfortunately, LCP only supports a single persistent variable (▼)(▲)A persistent variable is one that is maintained with the same value across multiple actions. In Drafts, you can fill in a variable in the first action, then call that variable in the second action and get the same value., the [clipboard] variable.

In general I dislike clipboard hacks, as they clear whatever is on your clipboard and also render the clipboard variable itself useless in the actions. In this case, however, it's the only way. In order to get a recursive action working in LCP, we first have to load the action onto the clipboard, then place the contents of the clipboard in the URL action. Launch Center Pro has a parameter in its URL scheme called “url”, and if we put an action in that parameter, LCP will call itself and then call the URL. That basic action looks like this:

launchpro://?url=[URL To Launch]

Note that the URL you are launching needs to be encoded.

From here the process gets more complex. At first I thought I would need two actions, one to prep the clipboard and another to run it. Then I realized that we can do it all in one single action, but it requires quite a bit of encoding. First we have to copy the action we are repeating to the clipboard. Since LCP's built in clipboard actions support x-callback-url, we can chain another Launch Center Pro action to the x-success variable of the clipboard action, then call the contents of the clipboard in the url parameter of the action. In case this doesn't sound complex enough already, there are still a few more issues to consider as well (bear with me, it's worth it in the end).

The way the LCP URL handler works is to first look at the top level of the URL (the unencoded part) and fill in any variables there (that would be calling [prompt]s and [list]s and swapping the user's input for the variable in the code, as well as also replacing any [clipboard] variables for the contents of the clipboard). This means that if it finds any unencoded, bracketed variables, it will fill them in before the action runs. Since we want to place our action in the clipboard before we put its contents in the URL, the clipboard variable has to be encoded for the first part of the action, which means placing it in the URL parameter of a Launch Center Pro action. Unfortunately, placing it one level deep isn't quite enough. Due to how the URL handler works, the URL action on the clipboard has to be placed in the action before LCP parses the level of the code that the clipboard is on. I know that's a confusing statement, so I'll try to clear it up below. Here's the action:

launchpro://?url=launchpro%3A%2F%2F%3Furl%3Dlaunchpro%253A
%252F%252F%253Furl%253D%5Bclipboard%5D

And here's the breakdown of that action:

First, LCP reads the unencoded portion of the URL, launchpro://?url=. All this does is call itself and step forward, unencoding the next level of the URL action. That may seem frivolous, but it's necessary when we are placing the action in the x-success variable of another action because we want to move a level away to avoid prematurely filling in the clipboard variable. Now the action, decoded by one level and with the first portion thrown away, looks like this:

launchpro://?url=launchpro%3A%2F%2F%3Furl%3D[clipboard]

At this point LCP sees a variable, [clipboard], and swaps it out for the contents of the clipboard. Since we are chaining this to a clipboard action that loads a URL action onto our clipboard, that will be what is placed here. Let's say the URL action we are loading simply launches Drafts, and thus would look like this: drafts://. Note that the part of the URL that the clipboard is being exchanged for is in an otherwise encoded region of our action. This is because LCP will not run a URL action from the clipboard if we fill it in in the same step that we are running it (I'm not actually sure why that doesn't work). Since we're placing it in an encoded spot, the action itself needs to be encoded too. However, it's also coming after a ?url=, so it has to be encoded for that as well. The result is that we double encode whatever is going in the clipboard. In this example, LCP adds drafts%253A%252F%252F (drafts:// double encoded) into the action from the clipboard, then calls itself, steps forward, and decodes and runs the next portion of the URL. Since the clipboard was just filled in, it looks like this:

launchpro://?url=drafts%3A%2F%2F

Finally, LCP calls itself once more, steps forward, decodes, and completes by running the simple drafts:// and launching Drafts.

So that's how we run an action which we have saved in the clipboard, but this is part of a bigger subject, so remember that all of that is happening in the x-success variable of an LCP clipboard action. The clipboard action is what is loading the hard-coded URL action onto the clipboard and then launching it later, and the entire thing (minus the action we're loading) looks like this:

launch://x-callback-url/clipboard?text={{[Your Encoded Action
Here]}}&x-success={{launchpro://?url=launchpro%3A%2F%2F%3Furl
%3Dlaunchpro%253A%252F%252F%253Furl%253D%5Bclipboard%5D}}

So now we understand how to hard code an action into the clipboard and then call that action later on in an x-success, but how does this allow for recursive actions? The key is that the clipboard is the only value in LCP's URL scheme which never changes. The first step is that your chosen action needs to support x-callback-url. Once you've picked an action, you simply use the same method that we used above for the x-success value, calling Launch Center Pro and running [clipboard] from the URL parameter. Let's use a Fantastical URL action as an example:

fantastical2://x-callback-url/parse?sentence=Test&add=1
&x-success=launchpro%3A%2F%2F%3Furl%3Dlaunchpro%253A
%252F%252F%253Furl%253Dlaunchpro%25253A%25252F%25252F%25253F
url%25253D%255Bclipboard%255D

This action launches Fantastical 2, sends it the word “Test” to be parsed, automatically adds the event, then calls x-success and decodes and launches the exact same LCP action that we broke down earlier:

launchpro://?url=launchpro%3A%2F%2F%3Furl%3Dlaunchpro%253A
%252F%252F%253Furl%253D%5Bclipboard%5D.

To finish, we encode our entire Fantastical URL and place it in the text parameter of the first LCP action, which saves it to the clipboard so it can be repeated (recall that the action needs to be encoded twice, but we can do one of these automatically within the code by wrapping the action, single encoded, in {{curly brackets}}. You still need to manually encode it once on your own though). Run the action in LCP and you'll get an infinite loop adding “Test” events to Fantastical (If you do run it, remember you can just press the home button to cut the loop). Obviously, that isn't very useful. What would be useful would be to have LCP throw up a prompt box each time so that you can add actual events. This is easy, just replace “Test” with [prompt] (although make sure it's encoded with the rest of the action as “%5Bprompt%5D”). Now if you run the action, LCP will prompt you for an input each time, meaning you can automate almost the entire process of adding multiple events to Fantastical directly from Launch Center Pro. The only difference between this version and the Drafts version is that in Drafts you write up the whole list and then call the action on everything at once, whereas in LCP you write one event at a time and then wait about one second for it to go add the event before jumping back to get the text for another. When you're finished adding, just hit cancel on the next prompt box and the process comes to an end.

Complete with the [prompt] input variable, the final product will look like this:

launch://x-callback-url/clipboard?text={{fantastical2%3A%2F
%2Fx-callback-url%2Fparse%3Fsentence%3D%5Bprompt%5D%26add%3D1%26
x-success%3Dlaunchpro%253A%252F%252F%253Furl%253Dlaunchpro%25253A
%25252F%25252F%25253Furl%25253Dlaunchpro%2525253A%2525252F
%2525252F%2525253Furl%2525253D%25255Bclipboard%25255D}}
&x-success={{launchpro://?url=launchpro%3A%2F%2F%3Furl%3Dlaunchpro
%253A%252F%252F%253Furl%253D%5Bclipboard%5D}}

That code block probably looks pretty daunting, but the best part about this method is that it's almost identical for any action you want to create. You can reuse that exact URL action, but simply change the Fantastical part, and get an entirely different action which works the same way. Just use this format, but paste in your own action (make sure it is encoded a single time!) in the designated area:

launch://x-callback-url/clipboard?text={{[Your Encoded Action
Here]}}&x-success={{launchpro://?url=launchpro%3A%2F%2F%3Furl
%3Dlaunchpro%253A%252F%252F%253Furl%253D%5Bclipboard%5D}}

Inside of your action, make sure the x-callback-url parameter looks exactly like this:

launchpro%3A%2F%2F%3Furl%3Dlaunchpro%253A%252F%252F
%253Furl%253Dlaunchpro%25253A%25252F%25252F%25253F
url%25253D%255Bclipboard%255D

(That is only single encoded, so you can place it directly on the end of the &x-success= value of whatever action you use before you encode the action. Don't forget that you will then need to encode the entire action before you paste it into the code template, so this part after your x-success will actually end up double encoded.)

The recursive Fantastical action is the most useful one I've come up with so far, but make sure to ping me if you come up with any other cool uses for this method of recursion.

You can grab the fully functional recursive Fantastical action we built above through this Launch Center Pro direct import link.

Fascinating concept of an interactive touch screen table-top. Something like this could completely change the jobs of waiters and eliminate a lot of friction in the ordering process.

The only part I’m not a fan of is the final aspect, where they start playing a game on their table while they’re waiting for the food to arrive. People come to restaurants to converse, and there are already enough distractions from that in the form of smartphones and other devices without making the table be another one. (▼)(▲)That said, it could be nice if the table allowed smaller games, or could just be a simple doodling surface as a way to occupy children during that waiting period before meals arrive. I worked in a restaurant as a busser last year, and many families are already bringing in iPads for their kids or even just giving them their smartphones to occupy them. If the table could do this, it could avoid the necessity of placing expensive devices in positions where they could have drinks or food spilled on them.

Via The Loop

Last week, Adam Kaplan released Grid, deeming it “A simple guide to responsive design.” I’ve been playing with the Grid system for the last few days and it’s fantastic. If you build, or are interested in building websites, you really need to check this out. Great work.

UPDATE: the Grid website seems to be experiencing problems. If you can get through then great, but if you can't then you can check Grid out in a less pretty format where Kaplan is hosting it over at GitHub.

The Verge:

Later this year, Taco Bell will start accepting orders via smartphone, according to trade publication Nation's Restaurant News. Rather than looking elsewhere for an existing mobile ordering solution, the fast food chain has reportedly spent more than two years perfecting its own system.

Say what you want about Taco Bell’s quality, but I’m impressed that they’re undertaking a fully custom solution for mobile ordering. Based on The Verge’s report, the app sounds pretty awesome, feature-wise. I especially like this aspect:

Taco Bell's app will also use your GPS location to determine when to start heating your food. To ensure that your meal is actually hot, that won't happen until you're nearing the pickup restaurant.

If they use geofencing on iOS devices, this could be a really useful feature while still not negatively effecting battery life by overusing the GPS. I’d love to see other companies start implementing mobile ordering systems with features like these. Namely, I think a mobile ordering system at Starbucks would be incredibly popular. Using the GPS system to know when to make your coffee so that it’s hot and freshly made when you arrive would be great.

Returning to Taco Bell, the features of the app are quite promising, but we’ll see if they deliver on a good, actually useable design. Furthermore, this will add another layer of complexity into the duties of workers in the store. Taco Bell needs to make sure employees are well trained and prepared for the rollout of something like this. I’m hoping since the service is entirely custom, this problem will be avoided.

In contrast, Tapingo, a mobile ordering service which we have on campus at the U of A, has seen problematic rollouts when entering new restaurants. In my experience it has been mostly worked out by this time in the year, but towards the beginning any mobile orders seemed to be of lower priority, and there was no good way to differentiate between people coming to get Tapingo orders and people actually waiting to order, resulting in long waits even though food was ordered early. These are the kind of problems Taco Bell is going to want to avoid.