Paul Thurrott tears Windows 8, and Microsoft apart:

The reason this happened is that while Sinofsky had the maniacal power and force of will of a Steve Jobs, he lacked Jobs' best gift: An innate understanding of good design. Windows 8 is not well-designed. It's a mess. But Windows 8 is a bigger problem than that. Windows 8 is a disaster in every sense of the word.

This is not open to debate, is not part of some cute imaginary world where everyone's opinion is equally valid or whatever. Windows 8 is a disaster. Period.

I grew up in a house where we used only Macs, and as a result was a somewhat blind follower and proclaimer of Mac OS X at school and with friends. I would often get into overly-heated arguments about how terrible Windows was and how everyone should convert to using Apple computers. Back then, I would have loved to see Windows make such a massive stumble, to be rejected fiercely by even its longest supporters, but now it’s just a bit sad. The war between Apple and Microsoft is over. Mac vs PC is a fairly outdated argument in the face of new technologies. Now watching Microsoft fail is almost painful, and I truly hope that they’ll find a way to return to relevance.

The young nerds of tomorrow will still be blindly arguing about the technologies that their parents chose for them. I hope Microsoft finds a way to stay in those disputes.

A bug in the current version of iOS 7 appears to allow users to disable Find my iPhone on a device without typing in a password, which effectively hides it from being located on iCloud.com.

This bug is dangerous and extremely easy to reproduce. All the more reason to keep a strong passcode on if you’re running iOS 7.0.4.

It appears to be fixed in iOS 7.1, but I hope Apple will rush a smaller update if 7.1 really isn’t going to be out until March, as rumors have been suggesting.

Yoni Heisler has compiled an impressive list of Apple references made throughout the seasons of The Simpsons and Futurama.

With a combined 33 seasons between them, both Futurama and The Simpsons are awash with references to Apple. Some of these references take the form of biting commentary while others are much more subtle.

It’s a great and entertaining list with more than 40 documented references and quotes from writers and directors of each series.

Agile Tortoise is the company behind some of the most innovative apps in the App Store. Drafts and Terminology are both essential apps to my iOS workflows, and with the release of Phraseology 2.0, Phraseology is now jockeying for position as my text-editor of choice.

Phraseology 2.0 finally updates the app to a more modern, iOS 7 inspired UI. Just like other Agile Tortoise apps, Phraseology doesn't go along with iOS 7's design exactly. Greg Pierce, the one man behind Agile Tortoise, has created his own special look, and it's immediately obvious when you're inside of an Agile Tortoise app as opposed to something made by other developers. The refreshed visuals in Phraseology make the app fit in perfectly with iOS 7 while still maintaining a unique feel.

Phraseology 2.0 is the missing piece to the Agile Tortoise puzzle. Pierce's hard work has paid off with the creation of a small, tight knit mini-ecosystem of apps within the overall iOS landscape. Agile Tortoise apps are interwoven in a way that no other developer has been able to copy. Custom contextual menus in Phraseology give access to Terminology functions to look up or replace a selected word. Drafts contextual menus have a new ability to utilize the powerful features of the Phraseology Arrange and Inspect views, allowing you to quickly and easily manipulate your text by rearranging sentences or even full paragraphs, or to get an in-depth analysis of your writing. All of the apps support x-callback-url (▼)(▲)Which should come as no surprise since Greg Pierce was actually the inventor of the protocol., so jumping back and forth between them to utilize their unique functions is a simple and seamless task. The powerful synonym functions of Terminology have proven extremely useful to me to spice up my writing or swap out repetitive words, and the process of looking up and switching these words is beautiful in its simplicity. Send your completed essay or article over to Drafts to have access to your complete library of URL actions to upload it to Dropbox, send it out to an Editor, or upload it directly to your website. The power of inter-app communication between these apps is an amazing hint at the capabilities of iOS, and that all of it exists within the bounds of Apple's strict rules is amazing as well.

Phraseology 2.0 brings support for iCloud document storage, as well as Dropbox mirroring for two different ways to store your documents. While the app does not have full support for Dropbox storing anywhere in your Dropbox, it's only two taps to open the export menu and send your document directly to Drafts, where you could run your own custom Dropbox actions on it. This is not a complete solution, but it's the best you'll get for now and is better than no Dropbox integration at all.

The Phraseology documents menu now allows you to swap between viewing your documents in order of the date they were created, the last time they were modified, the last time they were accessed, or alphabetically by title. This makes getting to your documents easy even as the list grows longer and longer. A simple swipe to the right on any document in this view will allow you to send it to Dropbox if it's in iCloud, or to iCloud if it's in Dropbox. In some future update I would hope for the ability to save documents in both places at once so that I don't have to distinguish between the two.

Phraseology also supports an excellent Markdown previewing module directly from the side bar (which is ever present unless you hide it with the full screen button, in which case it is one tap away). I've found this quick access to a markdown preview to be extremely convenient when editing posts I've written for Unapologetic.

The Phraseology Arrange and Inspect views are also featured prominently on the side bar. The Arrange view separates your entire text (or just a selection of it if you press the button while text is selected) and separates it into paragraphs by dividing on line breaks. From here it allows you to drag paragraphs around and reorganize your document with great ease and efficiency. A small button that appears when this view is enabled allows you to switch from paragraphs to sentences, and dragging sentences around is amazingly more simple and quick than the slow process of selecting, cutting, and pasting sentences that we have to use to mimic this function in other apps. I can particularly see the arrange view being useful in school papers or particularly long articles, where you write so much that reorganizing at the end can be quite useful to make sure the thread of your thoughts move in the most sensible way.

The Phraseology inspect view has grown to become one of my favorite parts of the app. Tapping inspect for the sidebar brings up a screen divided into five subsections. Statistics displays totals for the number of characters, words, root words, sentences, average words per sentence and average syllables per word for your entire document, or just a selected portion of it. To the right of Statistics is Scores, which displays some intriguing numbers which I had never heard of, but have been enjoying looking at and thinking about as I've written articles from Phraseology. These scores consist of the Flesch Kincaid Reading Ease score, the Flesch Kincaid Grade Level score, the Gunning Fog Index, and the Smog Index. You can check those links to see exactly what each score means, but my favorite one to think about has been the most self explanatory one, the Flesch Kincaid grade level score, which has been driving me to make sure my writing ranks at a high level. I've found trying to beat my scores after each article has been an interesting and fun new way to push myself to better writing.

Below the Scores section is a Root Words subdivision. This area displays a list of every root word used in your document, and a number for how any times each occurs. Looking through every one is unnecessary, but it can be great to check out which words I've used most to help determine if there's anything I have been repeating too many times. To the left of Root Words is Parts of Speech, which of course displays a list of different parts of speech that you have used in your document, and how many times you've used each. Selecting a part of speech will filter the Root Words section to display only words of that part of Speech.

The final section of the Inspect view is a wider box below the other four spanning the whole width of the screen. This box is empty at first, but when you select a word from the Root Words section, the Occurrences box is filled with actual sentences from your document in which you used these words. From here you can tap the small “Select” button to return to your document with the word in the sentence in question selected.

Phraseology also includes a syntax highlighting mode which will highlight different parts of speech all throughout your document. I personally have never found much use in features like this, but I know some people do, and it works well if that's your thing.

What I love above Phraseology, and all of Agile Tortoise's apps, is the vast amount of innovation that these apps are expelling with every new release and update. X-callback-url and the Drafts URL action engine are some of the driving forces behind the iOS automation and inter-app communication initiatives. Clever manipulations such as Terminology integration for finding and replacing words, sending documents and back forth between Drafts and Phraseology, and using the Phraseology inspect and Arrange views to analyze and manipulate text sent from Drafts are all great examples of new and never before seen features and functionalities. Phraseology 2.0 tightens the seams between Agile Tortoise's apps even further, and widens the gap that Pierce is building between himself and other developers to come up with the most intriguing new ideas for how to make writing on iOS simpler, more powerful, and an overall better experience.

You can get Phraseology 2.0 for $1.99, a limited time introductory price, on the App Store, or as a free update if you already own Phraseology 1.

A tweet from Zac Cichy brought me to this article on a site called Blue Cloud Solutions. The author describes a process he calls “app flipping” in which you buy the source code for an already made game app, reskin it, pack it full of advertisements, then put it back up on the store and milk it for one month. After that month is over, you reskin your engine again and repeat the process. Here are a few excerpts to give you a better idea of the shit this guy is talking about:

In other words, leverage the work that someone else has done by licensing or purchasing source code. My drug of choice is Apptopia because you can get an app in the store immediately before having to re-skin. If you go to another source code marketplace, you have to re-skin the game before you can launch. It just adds time to your bottom line, although sometimes you can get powerful engines for cheap.

[…]

Without fail, the best place to place advertisements is at the beginning of the game. Use full screens and don’t be afraid to layer them. I use RevMob and Chartboost for iOS and launch them at the same time. It’s very aggressive, but it makes money.

The next is to place both these fullscreens on the Game Over action. The user jumps off a cliff and dies…BOOM you serve up both Revmob and CB. Same with when they hit the pause screen and exit back to the main menu. If they’re trying to leave the game, try to get them to leave in a way that makes you money.  These ad networks hinge on selling installations of other games so you need to get users to click on the ads, go to the app store, then install the displayed game.

[…]

The trick is display as many ads as possible. Banner ads typically refresh on a 40-60 second interval, so you need to keep a user playing for about that long OR find ways to increase the number of times banners are served up.

I don’t think I’ve ever heard of a more deplorable practice. Shit like this is everything that’s wrong with the App Store. It has decended from a pinnacle of opportunity to a mad money grab where people don’t care about the user or the experience, but just want to make as much money as quickly as possible.

“App flipping” and similar ideas are making it harder and harder for actually good developers to make money in the App Store. It’s devaluing the entire marketplace by packing it with worthless crap. I wish Apple would do something like check source code for apps and not allow those which are obvious clones of others to be released as new versions. What ever happened to the idea of working for your money and being proud of what you build?

John Gruber has some excellent thoughts on Microsoft and the new CEO. Here’s one quote, but you should check out the full article.

Successful companies tend to be true to themselves. The old Microsoft’s Windows and Office everywhere, on every device strategy was insanely ambitious, but also true to their culture. Apple has grown to eclipse Microsoft in financial size, but never set its sights on Microsoft-ian market share size. Google is unfocused at the edges, but it’s never tried to act like any company other than Google. Google makes operating systems and office applications, but in a decidedly Google-y way. The last thing Microsoft should do is attempt to be like Apple or Google.

On the second episode of Andrew J Clark’s one man podcast, Life and Code and Stuff, Andrew discussed a few maxims that himself and listeners of the show came up with which he thinks are important. I loved the maxims and his comments on them, particularly since my own adventures with starting The Axx and, later, Unapologetic give me some very personal connections to them. I’ve transcribed the maxims below, and added some thoughts based on my own experiences.

Don’t get cozy, sweatpants are the enemy.

This first maxim has applications far and wide, from major companies like Apple to minor bloggers like myself. Just because you take the lead, see a taste of success, or get noticed does not mean that you can just settle in and coast the rest of the way. Your previous successes will not continue to carry you forward for long. We live in a world that moves at a rapid pace. The biggest subject of debate one week will be forgotten by the next. If you make a splash, you need to use that opportunity to work harder than ever before and make a bigger one, not just settle back and think that now you’ve made it. If you don’t keep going, always trying to best your last best, you will fail. Your one success will be gone with the next news cycle.

I’ve had personal experience with this. Last April, just a few months after I started blogging for the first time, I woke up to the massive surprise that one of my articles on The Axx had been Fireballed. That day, my fledgling website went from less than 100 views on the average day, to landing over 10,000 in just one. By the end of April, 2013, The Axx had garnered over 27,000 page views. That was absolutely incredible, but unfortunately, I failed to follow Andrew’s first maxim in the aftermath. I didn’t follow up my big post with anything else worthy of great attention. I thought a Fireball meant I’d “made it big”, but what it had really done was simply give me an opportunity to make it big, an opportunity that I failed to take advantage of. Within days The Axx had tapered back down from the massive levels of attention it had been receiving. I did still maintain about double the paltry amount of average daily page views I had been getting, which was really great for my previously tiny site, but these levels were not nearly as objectively impressive as they could have been if I had worked harder on follow up pieces. (▼)(▲)If I sound like I’m putting all the emphasis on page views, please don’t mistake me for someone who cares only about such numbers. Page views are in no way the most important metric of a website, not even close, but they are the easiest metric to exemplify the rise and fall of a website’s overall success for various time frames, so they’re appropriate here, I think.

I don’t regret what happened in April at all. Being Fireballed was an honor that I will never forget, and even though I missed the opportunity to keep hold of all of the new readers, it was a fantastic learning experience. Firstly, it taught me that I am worthy. It showed me that I am capable of producing work that tens of thousands of people will be interested in, and this endows me with a confidence that I (foolishly) never would have had beforehand. I say foolishly because there was no reason to doubt myself, as there is no reason for anyone reading this or anyone at all to doubt themselves. I knew in my heart that I had something to contribute, that’s why I started The Axx in the first place. If you’ve had the courage to start a blog, that immediately should prove to you that you have something worthwhile to contribute. If you are even thinking about starting a blog, that should prove it to you as well.

The second thing the Fireball taught me was exactly the lesson that this maxim is trying to teach us all: don’t get cozy. Just because you make a splash does not guarantee continued success. In fact, it guarantees nothing. It is, however, an opportunity, and I argue an opportunity is even more powerful than success. Success has boundaries. (How much further can John Gruber go now that he’s reached critical acclaim?) An opportunity is bounded only by imagination, determination, and will.

Try something new, say yes more often.

Definitely think this is a big one. It’s very easy, if an opportunity presents itself, to, to second guess it; to worry about what happens if it fails, or worse yet, worry about if it succeeds. I think, sometimes, the scariest thing of a new venture, a new proposition, is that it will work and it will demand everything of you, as most new ventures do. But, on the whole you’re better to say yes to most things.

Personally I cannot say that I have experienced the fear of success, although I know many have. Rather, it is another ugly face of self doubt which plagues me: the fear of failure. From school to sports to blogging, failure has always been something I’ve feared. Trying something new instead of staying in the same old tracks and doing the same old thing means facing this fear, and that fact made starting The Axx really difficult for me. I postponed it for many months before finally deciding that it was time to say yes to what my heart was telling me to do. As it turns out, that was one of the best decisions I’ve ever made. The new people I’ve met and the new places I’ve gone all because of finally saying yes and following my dream have been incredible. Certainly the work is demanding, writing a blog and being a full time student both at once is extremely difficult. It does demand everything from me, but it is absolutely worth it.

Make bad stuff, then make better stuff, and don’t be afraid to ask for help. That is a paraphrasing of the quintessential Jake-ism from Adventure Time that I, at the moment, am living my life by because I make a lot of things that are not very good. A lot of apps, a lot of podcasts, whole lot of tweets, whole lot of websites. But as Jake so awesomely says in many online GIFs: “Sucking at something is the first step to being sort of okay at something.”

I think it’s very handy to try to keep a little bit of perspective when the thing you like is not getting linked to, not working, crashing on launch, whatever, whatever the case might be. It’s all a process. Everyone is on a path. Sometimes all you can do is stay on the path and hope it leads somewhere eventually.

Particularly in regard to starting a blog, this one is vital. When you first start out, you will not have a large audience. You will probably not get linked to, probably not get retweeted or even favorited. The thing is, it doesn’t matter. The only way you’re going to build an audience, the only way to start, is to put your best foot forward from the very beginning. Make yourself known by socializing with people in the community. Twitter is an amazing place for that. I can attest that the people of the tech community are some of the friendliest people I’ve ever known. Talk to them, comment on what they tweet or write, and when you’ve written something you think they’ll find interesting, gently prompt them with a link and a quick tweet telling them they might enjoy it. The one thing you should not do is beg them for retweets or links on their blogs. If what you’ve written is good enough, they’ll retweet it themselves or link to it themselves.

An experience I’ve had with the first part of that maxim regards starting Unapologetic. While I would not call The Axx bad, I fully believe that it was not nearly as good as this new site is. When I first started out, I was eager to get going before I lost my motivation. This meant going with a Squarespace site was the smartest move. I chose the quickest name I could think of and the simplest design I could build and got down to writing. The Axx worked great, but it was never the full vision I had for my website. I dreamt of writing my own code from scratch, having a name I was proud of, and being completely free to do anything I wanted. Restrictions have always annoyed me in all parts of life, so Squarespace could never have been where I stayed. (▼)(▲)That’s not to be taken as a bash against Squarespace. In fact, I love the Squarespace and think it’s one of the greatest services on the web today. My dream simply included writing my own code. That’s why I moved from Squarespace and left the meaningless name “The Axx” behind. I had made something which, in some aspects at least, was “bad”, and then I made something which was better. Even on my second round, I ended up unhappy with Unapologetic’s host and moved from the restrictive Cloud Cannon to the free and unrestrained Host Gator. Iteration, this will always be the key. You won’t do it right on your first try, ever. This does not mean you should give up, it means you make something better on round two, and even better than that on round three.

Do more stuff in public.

I think that’s really nice. I think my experience is the more honest and open I am on Twitter, with friends, with family, with my girlfriend, the better stuff tends to work out. And it makes sense if you think about it. If people can see that you’re a real person, that you’re trying, even if what you’re doing isn’t working, they have a whole lot of compassion for that. You’re no longer just another voice screaming for attention, you’re a human being. You’re flesh and blood.

I admittedly do not follow this one very well, but it’s one I’m now going to work on. Currently I have two Twitter accounts so that I don’t have to bother my friends with my tech stuff, or my tech followers with my personal stuff. While I do think that’s a generally good practice, as my friends following @ajguyot don’t want their timelines filled with technology tweets and those of you who follow @the_axx don’t care about some of the Tucson-specific or inside joke tweets, after listening to Andrew’s podcast I think I’ll work on blurring the lines a little more. My friends know I like tech, so they won’t be too bothered if a little more of that is filtered in, and I want the rest of the world to know who I am a bit more instead of just seeing me chime in on the latest news and geek out about URL actions.

Don’t panic when shit is out of control.

Yeah, um, so many things spiral out of control. I think that might be one of the big keys to actually being a person that does anything in this strange world we live in, that things are going to fuck up a whole lot. Like it’s just part of the process. You can launch a website, or a podcast episode and it turns out the MP3 file is corrupted or everyone is linking to the wrong blog post and everything is spiraling out of control and the money that you had set aside for the music in your short film has run out and everything kind of threatens to careen out of control, but… but that’s okay. You’re not gonna get eaten by it. You’re not gonna get killed by it. It may suck, it may turn out well, but usually things do just turn out the way that they turn out, and panicking because you’re not able to control and micromanage every little factor of a thing and it does get too big for you to, sort of, to control and hold onto, doesn’t usually result in your world ending or your untimely demise. It usually means you have to hold your breath for a second, for a minute, for a week, for a year, but you come out of it on the other side eventually. Seventy years from now, on your death bed, surrounded by robots, you’re not gonna be thinking about the thing that failed.

At some point, you are going to mess up. I’ve done it, John Gruber’s done it, everyone’s done it. I have linked to articles that turned out to be false, I’ve written thoughts that turned out to be really dumb, I’ve posted URL actions that actually don’t work. When this happens, it sucks. It’s embarrassing, but it’s not the end of the world as long as you handle the situation properly. By that, I mean don’t stick to your guns when you’re in the wrong. Don’t keep defending your position if a huge flaw has been pointed out in your argument. Don’t keep pretending that the thing you linked to was correct when you know it wasn’t. Don’t tell everyone the action doesn’t work because they made a mistake when they installed it if it’s really just bad code. Take the blame for your own mistakes, apologize if necessary, update posts if necessary, and then go right back to working hard and striving for greatness. Everything will be forgotten within just a few days and no one will think less of you. In fact, many will think higher of you with the knowledge that you aren’t afraid to make mistakes, and will admit to them when you do.

On the other hand, what this doesn’t mean is that if you have a completely valid argument or article which someone else disagrees with and attacks you for, you should back down. Quite the opposite, you need to be, cough, unapologetic in regard to your own work. You know the difference between making a mistake and making a valid point or a great post, and if it’s the latter that you’ve made, stand behind your work no matter who tries to assault it.

There is no trick to getting known. There’s no trick to getting people to talk about your thing. If you make something good, then slowly, eventually, piece by piece, bit by bit, people will find it. If they’re not finding it, then either the thing you’ve made is not actually that good, or you haven’t communicated effectively why it might be good, so no one actually ever gets into the door. But you can get both of those kind of right, you will find an audience. There are people out there in exactly your situation, who need exactly what it is you’re trying to tell them. If you don’t have many followers on Twitter, well, maybe you’re just not actually tweeting the right things. Maybe you’re actually not really sharing enough of yourself on Twitter.

This is the cardinal rule. Do good work and eventually you’ll get noticed. I think it often starts with a niche. For blogging, mine was URL schemes. If you’re also interested in that blogging, yours may be something different. Everyone has something which their perspective is unique about, find your niche and take as much advantage of it as you possibly can, then expand. Not explicitly in that order, but if you only comment on the things everyone else is talking about, you’ll never get away from the crowd. You don’t need a niche, although if you have something that really interests you and you know a lot about then it certainly helps, but otherwise just experiment in a lot of different areas of discussion. If you diversify your blog and seek out interesting subjects that are not necessarily in the mainstream tech press then you can easily draw an audience like that as well. Just don’t be scared. Simply because John Gruber or Jim Dalrymple have not yet linked to something on a particular subject does not mean that no one cares about it. Who knows, if you write something unique then maybe they’ll link to you. If a 17-year-old high schooler with three months of blogging experience can be linked to, anyone can.

What it comes down to is this: the one and only way that you will never know if you are worthy is if you never have the courage to try.

On one hand, this is an awesome move, and if it became widely adopted it could bring millions of new students into the computer science field. That would be an incredible change for the industry and the future.

On the other hand, I fear kids will see programming as an “easy way out” of their language requirement. The classes could get flooded with kids who simply want to avoid having to learn a second language and think this will be easy. That could have a negative impact on U.S. citizens falling behind in knowing other languages, as well as possibly resulting in many lazy programmers who don’t really care about the field and simply want to do as little work as possible to get their second language requirement.

Today Apple updated its Mac 30th Anniversary page with a new video, “1.24.14”. The video was shot by Apple on the Mac’s 30th Anniversary, and the incredible part is that it was shot almost entirely with iPhones.

From a single command center, director Jake Scott (son of Ridley Scott, who directed Apple’s famous 1984 ad) coordinated filming in 15 different locations all over the world. Using FaceTime to be present at every set, and even to watch and direct the footage as it was being taken, Scott was able to cut the time a massive filming venture like this would usually take by an incredibly huge margin. The video is really amazing, as is the site they built to describe the process, which goes into much more detail about their innovative approach to the production. I’d be surprised if more filmmakers didn’t start trying something like this themselves.

Earlier this month, Federico Viticci wrote an excellent post regarding the possibilities of the rumored “iPad Pro” (▼)(▲)I won't go into the specifics of the rumors here since Federico already researched and discussed them extensively in his post, so check them out there if you're curious.. Viticci pondered the options for such a device, and came up with three possible manifestations of the most likely outcome:

Simply, a bigger iPad:

The obvious candidate would be an iPad Pro with a larger screen and no exclusive hardware or software features. Just like the iPad Air and iPad mini are essentially the same device with a difference in weight and size, the iPad Pro would be an addition to the iPad family with no major internal or software changes.

A “Pro” iPad With Substantial Software & Hardware Changes:

I’m mildly intrigued by the idea of an iPad Pro that, as the invented name suggests, would target pro users with substantial hardware and software changes.

[...]

Apple could make notable changes to the user experience and beef up the hardware to entice the pro audience. The 64-bit CPU of the A7 is a solid foundation to build upon, and if Apple could make that even faster without impacting battery life, while driving a larger screen and adding more RAM (needed) and a more powerful GPU in the process – at that point, interesting possibilities would open up to developers and users.

Or a hybrid:

The third option is, according to an analyst’s report, the hybrid. An iPad that “could serve as both a tablet and a notebook”.

Viticci discusses the pros and cons of each option after stating them, and I highly recommend you read the complete article. At the end, he concludes:

On multiple occasions, Cook said that they consider the tablet market “huge”. I don’t think that a larger iPad – laptop convergence or not – is the answer Apple and consumers are looking for, and I don’t think that a bigger screen would empower millions of people as much as a better iOS could.

“A better iOS”. Three words which I've been thinking about since reading Federico's post. I absolutely agree that, regardless of whether or not Apple is going to release a bigger iPad, significantly changing the software to be more powerful than versions of iOS for smaller screens is not the answer. That's not a better iOS overall, it's a single instance of a better iOS, and the existence of that instance would fragment iOS as a whole. iOS's unity is one of its most compelling features, so breaking it, making users choose whether they want the most powerful version or the most portable version, results in a worse iOS overall. Maybe the argument goes that this iOS will only be targeting the enterprise, but when has Apple ever been a company to do that? Steve Jobs once set out to bring powerful computing to the masses, and Apple as a whole has continued to follow that vision in various materializations ever since. Following this vision, iOS has brought computing to the masses in new forms and in greater numbers than ever before. Why would Apple change its course on that mission now and target only a small portion of the market?

Instead of fragmenting iOS and giving better features to a smaller market, Apple needs to take advantage of the mass market success that it already has. It needs to concentrate on improving the iOS that already exists in the hands and homes of hundreds of millions of people. The newest hardwares on iPads and iPhones boast 64-bit architectures, Apple's powerful A7 chips, ridiculously long battery lives, and beautiful retina displays. Certainly this hardware still needs improvements, particularly in RAM and memory, but in terms of raw power these devices are now capable of a lot more than iOS is currently allowing them to handle.

iOS needs to improve to bring new power and capabilities to the masses, to make new dreams possible and empower more people. This doesn't require a larger iPad, it requires, as Federico stated, a better iOS.

A Better iOS

What can Apple do to improve iOS? Well I've been thinking about that since reading Federico's article, and I've put together a few examples of new capabilities that could make iOS significantly more powerful without losing its inherent simplicity. The main caveats to thinking about improving iOS is that it needs to be both screen size independent, and invisible if it's not needed. For iOS users who are not power users or who do not want impediments to the simplicity of the system, these features need to stay out of the way. Allowing iOS apps to be shrunk down into smaller windows and moved all over the screen, one of the popular rumors for the supposed iPad Pro, breaks both of these basic principles. These examples, however, do not:

Windowless Apps

A concept inspired by Benjamin Mayo, Apple could go in the exact opposite direction of windowed apps. While forcing all developers to update their apps to be responsive in height and width and fit into arbitrarily sized windows would be a horrible idea, giving developers the option to have a mode in which they require no window at all would be easy, and is completely screen size agnostic. As Mayo suggests:

Apps should also have the capability to be ‘faceless’, so that other apps can query for data without needing any intermediary UI. This would enable apps like to draw on information available in other apps without pushing additional UI.

This idea is reminiscent of the integration already implemented between Greg Pierce's Agile Tortoise apps. When writing in Drafts or Phraseology, Pierce has customized the contextual menu that appears when you tap and hold or make a selection. Beside the standard “Select All”, “Copy” and “Paste” options, Pierce has added “Te:Lookup” and “Te:Replace”, among a few others. Selecting one of these choices will utilize the URL schemes and x-callback-url support built into the apps to launch you from Drafts or Phraseology directly into Terminology with the selected word in the search box. From there you can simply read the definition and return to the source app, or you can select a different word from Terminology's fantastic synonym engine. This activates the “Replace” feature, and when you return to the source app the word that you had selected is automatically replaced by the word you chose in Terminology. This functionality is already powerful and useful, but what if the entire process could be achieved without ever having to leave Drafts or Phraseology? If Terminology could just provide the data to be popped up in a small UI akin to the current one used by the system dictionary, and from there you could still use the powerful replace feature without ever switching apps, that would be an amazing new ability for iOS. Beyond definitions and single word swaps, apps like Text Tool could be activated from a contextual menu, and their actions used to transform an entire selection of text in some way or another. You could run an action to upload the document you're working on to Dropbox and then put the link on your clipboard, all without leaving the app you wrote it in. I'm thinking of every task that we currently use action chains in Drafts or Launch Center Pro to complete, all available to be launched in the background, from any app, without requiring any visible application switching. If Pythonista could run scripts in the background in a similar manner, possibilities become nearly endless. All this has been functionality that we already have, simplified. If we think beyond what we can currently do with URL schemes, more powerful prospects that we wouldn't even consider in the current state of iOS become feasible.

All this sounds nice, but a big question still remains. If Apple adds all of this background functionality, where are they going to hide the triggers for the actions in a way that won't layer complexity onto iOS? As it happens, they've has already solved this problem.

Control Center

Control Center, introduced with iOS 7, is a small, transparent panel that extends upward when you drag up from the bottom of the screen on any iOS device. Control Center is a really nice addition to iOS, but in its current form it is the epitome of untapped potential. Imagine a Control Center in which the icons to open the clock or camera app where customizable and in greater supply. Currently, on the iPad, Control Center extends to only a small fraction of the height of the screen, and includes two of these app buttons. What if Control Center extended twice as high and revealed two rows of customizable buttons which could be configured, like a Launch Center Pro main screen, to not only open apps, but run actions or workflows like the ones mentioned above? Alternatively (or even in tandem), after swiping Control Center into view, it could become horizontally swipeable, revealing more of these function slots, or other features such as multi-slot clipboards. On the iPhone, where Control Center is already pretty large and would look bad if it extended any further, horizontal swipes could reveal all of the custom functionality. Regular users who are uninterested would never have to think about it; power users would have a field day.

Improved External Keyboard Support

Power users love using the keyboard to navigate their devices. iOS should be no different. Apple needs to add stronger support for external keyboards, making it possible to navigate iOS without having to touch the display nearly as much. If the capabilities and Control Center actions I discussed above were implemented, the external keyboard would need to be able to open Control Center (▼)(▲)This is vital. Have you ever tried to open Control Center while the bottom bezel of your device is stuck into an external keyboard? It depends on the design, of course, but with my ZAGG Keys Cover on my iPad Air, getting close enough to open Control Center is really difficult. and navigate and choose actions to run from whatever a user has set up. Furthermore, users could bind actions to custom keyboard commands, and these would work anywhere across the entire system, regardless of whether the software keyboard would be visible or not at the time.

To Infinity and Beyond

Both a pro and a con of the functionality that I described above is that in general it doesn't call for any tasks to be made possible which cannot already be done on iOS through our URL schemes. Windowless apps are the closest to being an exception to that rule, but even that kind of functionality can be hacked together through URLs with enough collaboration, as shown by Agile Tortoise. The advantage to most of this being possible is that Apple could theoretically implement these features fairly easily, without completely changing the manner in which iOS works. The disadvantage, however, is identical. iOS is seven years old now. It has matured in many ways from its original state, but its stand on sandboxing and inter-app communication has not. It's time for these facets of the OS to mature as well. (▼)(▲)I'm not saying Apple needs to completely open up the system. Sandboxing certainly provides the benefit of iOS' famed security. However, it could be loosened to allow more powerful features without being completely removed, and security could still remain just as strong. If Apple changed the rules, the possibilities described above could simply be small steps toward a universally better iOS, bringing empowering new features to the entire line of iOS devices, big and small, and enabling new avenues for creation and creativity which all of the hundreds of millions of iOS users could pursue.

Yesterday, John Gruber released an update to his Make Bookmarklet Perl script. The script performs the following functions, as stated on Daring Fireball:

My solution: A “Make Bookmarklet” Perl script that I run as a BBEdit filter that (1) takes as input a file containing JavaScript source code; (2) creates a bookmarklet URL from that source code; and then (3) places the bookmarklet code in a comment at the first line of your JavaScript source, but otherwise preserves your original script.

Bookmarklets are a key ingredient to a few of my Safari workflows on iOS. Most notably, when I want to link to a post on Unapologetic. I copy the text I wish to quote on the webpage, then run a bookmarklet which launches Drafts and creates a new draft with the title of the webpage and the URL formatted as a link in Markdown, and the copied text formatted as a Markdown blockquote. I have a few other bookmarklets too which I use less often, but the one thing they all have in common is that they were exceedingly annoying to manually create on my iPad.

I hadn't known about Gruber's script until I saw its update yesterday, but when I saw it I knew immediately that it was a function I wanted to be able to have access to on my iPad, not just my Mac. So, I set to work converting Gruber's Perl script into a Python script that can be run from Pythonista on an iPad or iPhone.

My script performs basically the exact same function as Gruber's. You can send your JavaScript code to Pythonista by running a URL action in Drafts, an Editorial workflow, or by simply pasting your code into the script itself in the designated area and hitting the run button (this is the default). If you choose to run the script by the default option, I purposely left a single space on either side of the input zone, marked [YOUR CODE HERE], in case the code you paste in begins or ends with a single quote, which would break the three single quote comment block method being used to set the code as a string in the Python script. Leaving a space on either side will not affect your bookmarklet, as line-leading and line-trailing whitespace is removed by the script anyway. (▼)(▲)If you run the script using the Drafts action or Editorial workflow you do not have to worry about leaving spaces.

Using Gruber's example from DF, if you were to send the Make_Bookmarklet python script the following code:

var str = document.title;
alert(str);

It would result in this code being printed to the Pythonista prompt page:

// javascript:var%20str%20=%20document.title;alert(str);
var str = document.title;
alert(str);

And this bookmarklet being copied onto your clipboard:

javascript:var%20str%20=%20document.title;alert(str);

Since there is no main document like a BBEdit text file for the code to be placed on, I just have Pythonista print it so that you can copy and paste it anywhere you wish. The bookmarklet itself will be on your clipboard when the script completes, so you can go straight to Safari (or whatever browser you use), bookmark the first page that comes up, then change that bookmark title and paste your bookmarklet in for the URL.

My script also mimics Gruber's in that if you run it on code which already has a commented out bookmarklet on the first line (i.e., the first line contains // javascript: somewhere inside of it), the script will cut that line out before running, so you can keep recycling the code printed out by Pythonista until you've gotten the bookmarklet right. If you wanted to, you could set it up to open the code as a new draft in Drafts or in a file in Editorial each time instead of just printing it in Pythonista. Then you could immediately go back to editing the script without copying from the Pythonista prompt and pasting it somewhere else.

Gruber set his script up to not encode every character, making the resulting bookmarklet more readable. Mine encodes a little bit more than his, but leaves some of the most popular characters unencoded. If you want encode everything you possibly can, just remove the characters in the safe= parameter of the urllib.quote command on line 31. If you want to encode less characters, add those you don't want encoded into that same parameter.

Source Code to Make_Bookmarklet Script for Pythonista

import sys
import re
import clipboard
import urllib

if len(sys.argv) > 1:
	source_code = sys.argv[1]
else:
	source_code = ''' [YOUR CODE HERE] '''

split_code = source_code.split('\n') # Split code at newlines

# Remove first line if it is already a bookmarklet
if '// javascript:' in split_code[0]:
    split_code.pop(0)

source_code = '\n'.join(split_code) # Rejoin lines of source code without bookmarklet line (if it was present)

# Strip line-ending and line-leading whitespace
for i in range(len(split_code)):
    split_code[i] = split_code[i].rstrip()
    split_code[i] = split_code[i].lstrip()

bookmarklet = ''.join(split_code) # Rejoin code as bookmarklet with newlines removed
bookmarklet = re.sub(re.compile("//.*?\n" ) ,"" ,bookmarklet) # Kill commented lines
bookmarklet = re.sub(re.compile('/\*.*?\*/',re.DOTALL ) ,'' ,bookmarklet) # Kill block comments
bookmarklet = re.sub('\s\s+', ' ', bookmarklet) # Space runs to single spaces, tabs to spaces

# UTF-8 encode and URL escape
bookmarklet = bookmarklet.encode('utf-8')
bookmarklet = urllib.quote(bookmarklet, safe='=;()+?!')

bookmarklet = 'javascript:' + bookmarklet # Append 'javascript:' before bookmarklet

print('// ' + bookmarklet + '\n' + source_code) # Print full source code with new bookmarklet as commented first line
clipboard.set(bookmarklet) # Put bookmarklet on clipboard

Running the Script With Code Sent From Drafts

If you want to send JavaScript code from Drafts to be made into a bookmarklet in Pythonista, you'll need to import one Drafts action and make sure that your Pythonista script is named “Make_Bookmarklet”. (▼)(▲)If you really want to name your script something different, just make sure you change the name in the Drafts action as well. The Drafts action utilizes the [[selection]] variable tag. This means that if you want to write your JavaScript inside of a larger body of text, then select only what you want to be made into the bookmarklet and then run the action, only the code that was selected will be sent. If you do not make a selection before running the script (i.e., you want to send the entire contents of the draft to be converted), the [[selection]] tag will act identically to the [[draft]] tag, sending the whole draft as most other actions do. (▼)(▲)Hat tip to Charles Bucher

Direct Import Link for “Make Bookmarklet” Drafts Action

Running the Script With Code Sent From Editorial

To run the script from Editorial, import the workflow below. Instructions are identical to those for Drafts: the Pythonista script must be named “Make_Bookmarklet” and the code sent will either be whatever text you have selected in Editorial or the entire document if you have no selected text.

Direct Import Link for “Make Bookmarklet” Editorial Workflow

Feedback

If you see any errors or have suggestions for the script, please contact me with them.

UPDATE:

Tweaked script so it senses whether it is being executed with a sys.argv argument (i.e., from an external source like Drafts or Editorial or from holding down the run button and typing code manually in Pythonista). If it is then it will use that argument for the source_code parameter, otherwise is will use the code in the [YOUR CODE HERE] slot.

While building Editorial workflows, I've often run into times in which I wanted to launch Drafts and run an action that I've previously built and have in my URL action library. I've grown tired of having to remember and put together the necessary blocks in Editorial, so I created a couple generic groups of actions to save as presets so that I can easily add Drafts actions into my Editorial workflows.

The groups of actions are bundled as their own workflow. Import the workflow into Editorial, then choose edit. There are two options for the presets, one for a simple Drafts action which creates a new Draft from your input text and runs a single action on it, and one for a chained Drafts action which creates a Draft from your input and runs an action on it, then chains back and creates another draft from the input and runs another action on it. Since I'm not aware of any standard way to bundle groups of actions, I placed each set within an “if.. end if” block. Save the block as the preset, then each time you want to use it just drag the if.. part down to the bottom so that the actions pop out and then delete it. There's a brief video below showing how easy it is to use this to add a Drafts action into your Editorial workflows.

One last note: remember that the action title in the first action needs to be manually URL encoded, and the action in the chained URL needs to manually double URL encoded. Same with the input, but the action groups do that for you.

Direct Import Link for the “Drafts Actions” workflow.

Tab Atkins Jr., a member of the CSS Working Group, reveals a nice tip about single line comments in CSS using //:

CSS uses the same “block comment” syntax as the C-like languages - you start a comment with /*, and end it with */.

However, CSS is missing the “line comment” syntax that those languages have, where everything from // to the end of the line is commented out.

People have asked for this syntax to be added repeatedly, but unfortunately our hands our mostly tied - CSS minifiers don't know about line comments, so if we added it and the minifier removed all the linebreaks (as they tend to do), the line comment would accidentally comment out the entire rest of your stylesheet!

That said, CSS does actually already allow you to use //, after a fashion. It's not quite a line comment, but a next construct comment.

That is, whenever you use //, the next CSS construct - either declaration or block - will be “commented out”.

I despise having to add the extra */ at the end of every CSS comment block, and having to remember to remove it every time I want to uncomment something annoys me even more. This is a tip I'll be using quite often.

Pythonista has a built in Dropbox module to allow you to manipulate files on your Dropbox. The module itself is fairly simple and straightforward (assuming you know some basic Python), but when I first started scripting on my iPad, I found the online instructions for linking my Dropbox account to Pythonista to be unclear and overly complex. Since the implications of being able to write scripts which access and manipulate files on your Dropbox account are very powerful, I think that everyone should be able to do it. As a result, I've written below what I hope are significantly simplified, step by step instructions to help you circumvent the confusion I ran into trying to give Pythonista access to a Dropbox account.

Linking Your Dropbox to Pythonista

The first thing you should do to link your Dropbox to Pythonista is to copy and paste this script into a new empty script in Pythonista. You can name the script whatever you want, but I named mine “dropboxlogin”, and that's how I will be referring to it for the rest of this post (and in future posts involving Dropbox).

The first few lines of the dropboxlogin script are the only ones that you need to think about, don't touch the rest of the script. These lines are as follows:

# YOU NEED TO INSERT YOUR APP KEY AND SECRET BELOW
# Go to dropbox.com/developers/apps to create an app.

app_key = 'YOUR_APP_KEY'
app_secret = 'YOUR_APP_SECRET'

# access_type can be 'app_folder' or 'dropbox', depending on
# how you registered your app.
access_type = 'app_folder'

The directions here make the process seem pretty simple, but it gets a bit more complicated when you actually attempt to follow them. To start out, go to the URL in the script, as it tells you to. That will direct you to a page prompting you to log into your Dropbox account (assuming you aren't logged in already). After signing in you should be presented with a page that has a “Create App” button. Tap that button to get started.

The first option that you will be presented with will ask you if you want to create a “Drop-ins app” or a “Dropbox API app”. Choose the latter. Once you've selected Dropbox API app, the next option will appear below automatically. For this one, choose “Files and datastores”, for the next, choose “No – My app needs access to files already on Dropbox.”, and for the one after that choose “All file types – My app needs access to a user's full Dropbox.” Finally, choose a name for your app. Now press the “Create app” button.

The next thing you should see is an overview of your new “app”. You can ignore everything on here except for the “App key” and “App secret”. These two strings of characters need to be copied and pasted into the corresponding regions of your python script in Pythonista. Make sure you replace only the text “YOUR_APP_HERE” and “YOUR_SECRET_HERE”, so that the strings of characters are still between the apostrophes.

To finish off your script, change the access type from “app_folder” to “dropbox”, because we want Pythonista to have full access to our Dropbox for the most versatility with future uses of the Dropbox Module.

The dropboxlogin script comes with a built-in main method to test whether your efforts have been successful. Run the script from Pythonista and the interactive prompt should slide over, displaying the output “Getting account info...”. A few seconds later, a string of data should be written to the screen with information about your account. If there is an error then check to make sure your app is completely set up, that you correctly copied your app key and app secret into the right places, and that you chose the proper access type for the app you set up.

If you've followed all the steps correctly, you should be ready to go. Now anytime you want to be able to access your Dropbox via the Dropbox module in a different python script, simply include the line from dropboxlogin import get_client at the top of your script. The get_client method begins a Dropbox session, so if you include another line beneath the import command, dropbox_client = get_client(), then you can now call methods from the Dropbox module on your “dropbox_client” variable.

Happy scripting.

Last week the news broke that smart thermostat company Nest was being purchased by Google. There were quite a few concerns voiced in response to this announcement, most of which concerned privacy. On the day of the announcement, Nest posted a short announcement article and Q&A on its blog. One seemingly key piece in the Q&A section was the bit on privacy:

Our privacy policy clearly limits the use of customer information to providing and improving Nest’s products and services. We’ve always taken privacy seriously and this will not change.

While this sentence was certainly posted to alleviate fears regarding privacy, an interview with Nest CEO Tony Fadell yesterday brought about this comment regarding the privacy policy:

If there were ever any changes whatsoever, we will be sure to be transparent about it, number one, and number two, for you to opt in to it.

So while the current Nest privacy policy may limit the data garnered from the device to only be used to improve Nest’s products and services, Nest clearly has no qualms about changing that policy in the future to give more information to its new owner. Sure Fadell may say these will be opt-in only services, but Google doesn’t exactly have a great track record in tweaking privacy rules in a way that defaults to users being opted-out. I would not be too confident that this will change in the case of Nest.

Early last year I posted The Due Later Action Series on The Axx. The basic concept was to use the URL scheme of the timer app Due, combined with Drafts, to time delay the launching of a particular action. While the implications of such a workflow were powerful, I was never quite happy with the implementation. First off, I've never much liked the Due UI, and especially now that it has still not been updated for iOS 7, I prefer to avoid ever having to look at the app. Secondly, after the Due notification would go off, just tapping it would not launch the action. Instead, tapping it would launch Due and you had to check off the reminder as complete, then accept a modal dialogue before the URL action would be executed. Finally, while Due could parse a natural language description of the time to launch the action, you had to remember to double tap the reminder before you created it in order for that parsing to come into effect. I often forgot this double tap and ended up ruining the entire process. Overall the workflow was delicate, finicky, and unforgiving of the slightest error in the complicated steps to make it work.

That was in early 2013, and since then iOS automation has come a long, long way. Today I'm releasing a new workflow for time delaying your URL actions. This one no longer requires Due, and therefore can bypass all of the frivolous extra steps and having to look at the iOS 6 UI. I've been using the workflow myself for the past few days, and I find it is simple and straightforward enough that I actually use it and enjoy its benefits.

Using Pythonista and Launch Center Pro to Time Delay URL Actions

Pythonista 1.3, released in February 2013, came with a module to script notifications on iOS devices. This would probably have been a better choice to use for the original Due Later Action series back then too, but I didn't know any Python yet, Drafts didn't have any options to separate more lines than just the first and all the others, and Launch Center Pro 2.1 had not been released, either. (▼)(▲)It's also possible I just liked the pun in the title. LCP 2.1 brought a way to pop up a list of choices when running actions. Your choice in the list would change the action that was run based on the value attached to that choice. Using a combination of that list feature in LCP, along with its ability to label prompt boxes and utilize the number pad keyboard, we can remove the need to remember exactly how to format a plain text Draft to properly time delay an action. It's still possible to run the action from Drafts if you're not an LCP user, or if you're on an iPad, but the process is not quite as simple in that case. Regardless, I'll describe both methods below.

Running Time Delayed Action from Launch Center Pro

Running the Time Delayed Action action from LCP requires only one action, but you'll need to edit it based on the actions you want to be running. The raw code for my version of the action looks like this:

pythonista://Time_Delay?action=run&argv=[prompt:Text for Action]&argv=[list:Choose Action to Run|Cross Post|Tweet: ajguyot|Tweet: the_axx|Post to App.net]&argv=[prompt-num:Hours to Delay]

This action will launch Pythonista and send three parameters to the “Time_Delay” script. The first parameter, as labeled by LCP, is “Text for Action”, and should be self explanatory. The second parameter may be a little more confusing. It uses Launch Center Pro's list feature to allow you to choose which action to run. In this case it gives the option to run “Cross Post”, “Tweet: ajguyot”, “Tweet: the_axx”, or “Post to App.net”. Whichever choice is made will send that exact text to Pythonista. If you want to send different text than appears in the dialogue box, place an equal sign after the text, then the actual value to be sent. For example, [list:Choose Action to Run|Tweet=Tweet: the_axx] would display a dialogue titled “Choose Action to Run” with one option: “Tweet”. Choosing this option would send the text “Tweet: the_axx” instead of “Tweet”. If you don't include an equal sign, the text sent is identical to what is displayed as the option in the dialogue. Also important, make sure not to encode the titles of your actions in this list, the Python script will do that for you later.

For the final &argv= in the code, LCP will display a number pad prompt and ask how many hours you want to delay your action by. Pythonista can't parse natural language (or at least, I don't want to, nor would I likely be able to write a script that might allow it to do so), so we time delay based on hours instead of selecting an actual time and date. I actually like this implementation better. If it's late at night and I want to post a Tweet when I wake up in the morning, I just time delay by an hour or two, for a time when I know I'll be asleep, and the notification will be waiting for me in the morning.

When the notification does pop up, it displays in the form “Run [[action]] on [[text]]”. So if I chose to Cross Post the text “Hello World”, the notification that pops up would say “Run Cross Post on Hello World”, and tapping it would automatically do exactly what it says. This method avoids confusion if you set up multiple time delayed actions for the same time, or at different times but you don't look at your device until multiple actions are queued up. Now you can remember exactly what each action is going to do. If the text is too long it gets cut off, but enough should still be displayed for you to remember what it was saying.

Once your action has been scheduled, the script also appends the same text, “Run [[action]] on [[text]]” to a file called “Scheduled Actions” in Pythonista. This way if you decide you want to change the text, post it early, or not post it at all between the time you schedule the action and the time it goes off, you can still retrieve your text from the file in Pythonista.

LCP Actions

Make sure to edit the code of this action and switch out the placeholder options with your own action options. You can add more than the four placeholders by placing more pipe characters followed by more actions at the end, or you can remove actions if you don't want that many. By default the script is running a basic Drafts action of the form drafts://x-callback-url/create?text=[[text]]&action=[[action]], where [[text]] is replaced by your text and [[action]] is replaced by one of the action options you write into the main Launch Center Pro action. This means that you can use any Drafts action in your library for these options, so don't feel limited to just time delaying social media posts. (▼)(▲)As an example, I'll be using this workflow to time delay posts to Unapologetic. I write a lot of my posts on weekends or at 2 or 3 in the morning, and posting at these times is not optimal, as many people don't end up seeing the tweets. The ability to time delay the posts to a better time and then post them with a single tap will be really nice. Furthermore, if you want to time delay an action for an app that is not Drafts, you can read the comments in the Python script to find the one line to change in order to use a different base URL.

Direct Import Link for “Time Delayed Action” Action

Pythonista Script

Make sure to title your Pythonista script “Time_Delay”, or the actions won't call the right script.

import sys
import notification
import webbrowser
import console
import urllib

# Receive parameters from Drafts or Launch Center Pro and assign them to variables.
text = sys.argv[1]
action = sys.argv[2]
delay = sys.argv[3]

# Convert delay time into hours.
hours = float(delay) * 3600

# Encode action and text so they can bed used in URL action.
encoded_action = action.encode('utf-8')
encoded_action = urllib.quote(encoded_action, safe='')

encoded_text = text.encode('utf-8')
encoded_text = urllib.quote(encoded_text, safe='')

# Create URL. You can change this from a Drafts action to be something else if it better fits your needs.
url = 'drafts://x-callback-url/create?text=' + encoded_text + '&action=' + encoded_action

# Schedule notification.
scheduled = notification.schedule('Run ' + action + ' on "' + text + '"', hours, 'default', url)

# Append text for action and what action was run on it to a file called "Scheduled Actions" in Pythonista.
scheduled_actions = open('Scheduled Actions', 'a')
scheduled_actions.write(action + ' on "' + text + '"\n')
scheduled_actions.close()

# Return you to source app after action is scheduled. (Delete these last lines to just stay in Pythonista.)
webbrowser.open('launchpro://')
#webbrowser.open('drafts://')
# Uncomment line 35 and comment line 34 to open Drafts after success instead of Launch Center Pro.

Running Time Delayed Action from Drafts

If you want to time delay actions starting from Drafts instead of Launch Center Pro, things become a little more complicated. For starters, Drafts does not have the list feature that LCP does, so we have to either reserve a line to type the title of the action we want to run every time we run it (i.e., line 1 would be the actual typed title of the action to run, line 2 would be the number of hours to delay, and line 3 until the end would be the text to send for the action), or have a multitude of different actions specifically to time delay each type of action (e.g., have a “Time Delay Cross Post” action, a “Time Delay Tweet” action, a “Time Delay Post to App.net” action, etc.).

I can't choose which option is better for you, as both of them have pros and cons. If you have to manually type the action to run every time you want to schedule a time delayed action, then a single character typo would ruin the entire process. However, if you have a separate action for every single type of time delay you might want to use, then your action list quickly becomes very cluttered. Since neither option is perfect, I'll provide you with the code for both and you can pick which one you want to use yourself.

Don't forget that regardless of which way you want to run Time Delay Action, you still need to add the same Python script from above to your Pythonista library.

Drafts Actions

First is the action in which you have to hard code which action you want to time delay into every draft before you run it. This action requires no manual changes on your end after importing, but when you run it make sure that line 1 of your draft is the action you want to run, unencoded, but with NO typos (even a mistyped capital letter or an extra space at the end will ruin the action). Line 2 should be a single number representing the number of hours for which you want to delay your action, and the remaining lines will all be used for the text of your action. (▼)(▲)An advantage over LCP here is that you can time delay actions on multi-line text. The Launch Center Pro prompt keyboard does not have a return key, to my continued annoyance, so the only way to send multi-line text with it is if you paste in line breaks.

Direct Import Link for “Time Delayed Action” Action

If you've decided that hard coding the action into every draft to time delay is the better direction, you don't need to read the rest of this. Otherwise, the following action will be for those of you who wish to have specific time delay actions for each type of action to delay. This method will require you to tweak your action's code after importing it. Below I am providing a single template action. The template will use line 1 of your draft (which should be a single digit and no more) as the number of hours to delay your action, and line 2 and further as the text for the action. After importing, you'll need to change the code after the second &argv= to whichever action you want to run. (The words “ACTION TITLE” in all caps is in the code in the exact spot you need to change, so find those words and swap them with your chosen action title.) You will probably also want to change the title of the action to match whatever you're time delaying with it. If you want multiple actions set up, import the template code multiple times and change each one to the action you desire.

Direct Import Link for “Time Delayed Action Template” Action

Some excellent work from Eric Pramono over at Geeks With Juniors. He's figured out a way to use Alfred and Command-C to automatically launch URL actions on your iOS devices from your Mac.

By now, I'm sure you know that Command-C can send text/images from Mac to iOS. The problem with this built-in feature is the clipboard data still floats around the iOS pasteboard. What if we could put the clipboard data, assuming it's in text format, straight into Drafts instead?

To do this, we need to use the copyAndOpenURL action from Command-C. And, instead of sending just a string of text, we will send a Drafts URL Scheme instead. We can write the URL Scheme to create a new post in Drafts containing the text that's being sent from Alfred prompt.

But, we don't need to stop here. We can go even further by triggering any action that we already have installed in Drafts. All we need to do is define a delimiter to split the text we put in Alfred prompt into the text and action parameters of the URL Scheme.

My use for Command-C is unfortunately limited by the fact that it only works over local WiFi networks, rendering it useless for me in both my Dorm and at the coffee shops where I usually go to work. Still, there is some really powerful potential in this if you work in an environment with the right WiFi. You can launch any type of URL action from these workflows, so beyond Drafts you could also run Python scripts from Pythonista on your text, send it right into an Editorial workflow, or leverage any other app that has a URL scheme.

The Triple Cross Post action takes a draft (or a prompt in Launch Center Pro) and automatically cross posts it to Twitter, App.net and Facebook.

Running Triple Cross Post From Drafts

In order to work, this action requires the Cross Post Action to also be installed in your Drafts Action List.

Actions

Direct Import Link for Triple Cross Post Action.

Make sure to go into settings in Drafts and change “USERNAME” to your actual Twitter username in the code for the Cross Post action:

Direct Import Link for Cross Post Action.

Running Triple Cross Post From Launch Center Pro

Adapting Triple Cross Post to Launch Center Pro requires the installation of two extra Drafts actions (as well as the Cross Post action mentioned above), and one Launch Center Pro action. The Launch Center pro action is what you will launch any time you wish to Triple Cross Post. It will first display a keyboard prompt, and after typing in your post just hit return to start the chain to triple cross post.

Since LCP does not have built in Post to App.net or Post to Facebook actions for us to chain together, we have to use Drafts instead. After you hit return on the prompt in Launch Center Pro, LCP will launch Drafts, create a draft with the text of the prompt, and run the launchpro-tcp action on it. This action in turn will run the Cross Post action on the same text, posting it to App.net and Twitter, then it will chain back and run launchpro-tcp2. This action first posts your text to Facebook, then chains back to Launch Center Pro so that you end up in the same place you started from.

LCP Actions

Direct Import Link for Triple Cross Post Action.

Drafts Actions

Direct Import Link for launchpro-tcp Action.

Direct Import Link for launchpro-tcp2 Action.

Cross Post is only necessary if you did not already import it from the Drafts section above. After importing, make sure to go into settings in Drafts and change “USERNAME” to your actual Twitter username in the code for the Cross Post action:

Direct Import Link for Cross Post Action.

A few months ago, I tweeted about a Drafts guide that I was working on. Quite a few people seemed interested, but then it never ended up being posted. That's because I was contacted by Federico Viticci of MacStories with the offer of guest posting it on his site instead.

It took a little longer than we had expected, but today my work has come to fruition. If you're at all interested in iOS automation through apps such as Drafts or Launch Center Pro, but have never been quite certain how to get into the field, I highly encourage you to check out my guide. It was written with the goal of taking readers from having little to no knowledge of Drafts and URL schemes to being expert action builders. If you're already an expert on the subject, feel free to skip to the end, where I wrote my best tips and tricks on building more advanced and complex actions involving looping and chaining multiple apps and actions together.

You can find the guide on MacStories.

There were a few posts a few months ago on various tips and tricks about using the iOS software keyboard. Most of them talked about the ability to tap the “.?123” button and then slide your finger to choose a character from within that subset of keys. This method will also work with the caps lock key to capitalize a single letter with only a tap and slide instead of two taps. Small differences of course, but I've been using them for about four or five months, and while it takes a while to get used to them, once your fingers relearn how to operate the keyboard it becomes a much smoother and more instinctive way of typing. These kinds of tricks are an advantage that hardware keyboards can never compete with, so as software keyboard users we've got to take advantage of them.

I won't spend any more time reiterating what the linked posts above discussed, but I have noticed that none of them mentioned a trick I discovered which has become my favorite one of all. It regards the “,!” key located in the second row of keys from the bottom on the iPad keyboard, the third key over from the right. What many people (myself included for the first three years in which I used an iPad for almost all of my typing) don't realize is that if you tap on that key and then quickly swipe upwards it will immediately insert an apostrophe. Tapping and holding to reveal deeper functionality within the main keyboard keys is no secret, but what makes this key special is that there is no need to hold. As quickly as you can tap and swipe upwards and let go of the “,!” key is as quickly as it will place the apostrophe. This is significantly quicker than any other method of inserting an apostrophe, even using the apostrophes located on custom keyboards in apps like Drafts or Editorial. The exact same functionality works on the “.?” key, but inserts a quotation mark instead of an apostrophe.

It will likely take a while for your fingers to change the deeply ingrained behavior of tapping the “.?123” key and then tapping the apostrophe or quotation mark key from there (or sliding to it if you already use that method), but once you start using the quick tap swipe method described above, I find it makes my typing feel much more natural and less strained. Using this method, every one of the most popular punctuation keys are very small strokes of the finger away. Simply tap to get a period or comma, tap and swipe up promptly to get an apostrophe or quotation mark, and quickly tap swipe from the right caps lock key to the adjacent comma or period keys to immediately access an exclamation mark or question mark. If you start using each of these methods I guarantee that your software keyboard typing will feel more intuitive and have less slight irritations by cutting down the time it takes to use the most common keys.

As described in my last post regarding the new changes to Unapologetic, I've migrated all the necessities for posting to The Axx over to a new home here. My most recent automation articles are live here (▼)(▲)If you're interested in viewing those, you can find them by going to the home page of Unapologetic and selecting “Automation” in the view controller at the top., and in the coming weeks I plan to move my older automation articles over as well. What this means is that The Axx has finally become obsolete.

I won't go into detail here on my choice to leave The Axx behind, as I have already written about that decision in my first post on Unapologetic. At the time of that post I still planned on keeping The Axx around as a purely automation based blog, but that turned out to be a bad idea. So today I am officially announcing the end of The Axx.

Despite my pleasure at how Unapologetic has turned out, it's still sad for me to leave The Axx behind. I started The Axx on February 18, 2013, as a place to publicize my thoughts on technology and, especially, post my workflows for automating my iOS devices. This goal became the vision that I followed all throughout last year, and The Axx was the site within which it was realized.

I'm excited to continue my journey writing in this new home at Unapologetic, but I won't forget that The Axx is what brought me here. If not for The Axx, Unapologetic would never have existed, so to honor it, I plan to keep The Axx around as an archive of where I began. I reset all of the changes which I made when I was expecting to continue using it as an automation only blog, so now it rests in the original form I created it in, holding The Action Page and all of the content of the 78 blog posts I wrote there.

With The Axx peacefully at rest, and Unapologetic in its final form, now it's time to get back to what I love doing most: writing content. And I have quite a bit planned for the coming weeks and months.

I launched Unapologetic in early October, 2013, forking my old site, The Axx, so that long form articles would now reside on Unapologetic, while the URL actions I was best known for would take up a more prominent position as the main focus of The Axx. At the time, I justified this by saying that both types of content deserved their own specialized locations, but to be completely honest, I was in such a rush to ship Unapologetic that I chose to leave the actions at The Axx in order to avoid having to transfer each and every action article to the new site. (▼)(▲)This process could have been extremely easy if Squarespace supported a way to export all of my posts in Markdown. Since it does not provide such an option, manually pulling the text from each article was proving much more time consuming than I would have hoped.

Soon after launching Unapologetic, I realized that my decision to fork The Axx had been a mistake. Caught between two CMSs, having to leave my simple custom workflows for posting to Unapologetic from my Mac to return to the old Squarespace UI every time I wished to post to The Axx annoyed me to no end. I have nothing but respect for the service Squarespace provides, but interacting with the backend UI is often frustrating and prone to bugs. Furthermore, I found myself constantly faced with the conflict of whether articles which were mostly long form, but also automation themed, belonged on The Axx or on Unapologetic. Finally, I greatly prefer my custom, colorful design at Unapologetic to my old monotone design at The Axx, so posting new content to The Axx felt like I was displaying arguably my most important work in an inferior environment.

Beyond the annoyance of having two CMSs, I was even having second thoughts about my choice for the second one. I was using Cloud Cannon, a Dropbox based CMS which advertises itself as “steroids for web developers.” Unfortunately, I was not fully confident of its stability, as it has no uptime guarantees, nor any evidence that it can handle large traffic spikes. (▼)(▲)At this time, my humble little blog doesn't garner nearly enough hits on the average day for traffic to pose an issue to any hosting provider, but I'm not worried about the average day. Back in April when my post on The Axx was linked to by Daring Fireball, my traffic that day spiked to over 10,000 unique visitors. In the days afterward it rapidly declined, but the traffic and attention I received on that single day from that single link was almost as much as The Axx has received overall on every day before and since then. If another one of my posts ever gets linked to again, I need to be completely confident that my hosting provider will not crumble under a traffic spike on one of the most important days for my blog.

Perhaps a bigger issue than my lack of trust for Cloud Cannon's stability was my discovery that the “optomizations” it was making automatically on my site were actually changing certain aspects of my code. Sometimes pictures which I uploaded would be loaded onto the website horizontally, with no explanation and no way to change this except to not include the pictures in the post. Another example, Cloud Cannon took the link to my RSS feed, which should have been “feed://unapologetic.io/rss.xml”, and changed it into a feed://cloudvent.net URL, followed by a seemingly arbitrary stream of alphanumeric characters. I was helpless to stop this behavior from happening. I would include the link as it was, but at some point since I noticed, it has been reverted to its original form just as quietly as it was changed. As a result of these weird behaviors I'm now uncertain of how much I can trust Cloud Cannon not to mess with my carefully written code.

The main reason I chose Cloud Cannon was for its simplicity. All I had to do was drop my files into a folder in Dropbox and moments later they would be pushed to my website. I still think Cloud Cannon is a great tool, but it needs to learn not to go quite so far with its “optimizations”. Furthermore, I left Squarespace to be freed from restraint on what my website could do and how it appeared, and Cloud Cannon, while significantly more free than Squarespace, was still limited. With no support for MySQL, I could not implement Mint site tracking as I wanted to. With only limited support for includes, I could not create a template system quite as powerful as I wanted mine to be. These issues, and those stated above, are the main reasons for My choice to leave Cloud Cannon, and convieniently timed podcast sponsorships lead me to Host Gator next. Since I was already going through the trouble of changing hosts, I decided to put some finishing touches on Unapologetic which I had been rushing too much to implement back in October.

Since making these decisions at the end of October, I've been working hard to learn JavaScript, Sass, and the ins and outs of an Apache server. Lynda.com proved an amazing tool to quickly get up to speed on these topics. (▼)(▲)While I was at it, I also took some time to learned the basics of Objective-C and programming in Xcode, but the fruits of those labors won't be revealed for some time... I rewrote my CSS in Sass, threw in some Jquery tricks to finally satisfy the full vision for my custom footnotes, and built a JavaScript view controller so those who are uninterested in iOS automation can filter out those articles, while anyone who is only interested in iOS automation can see just my articles related to that subject. (▼)(▲)This is my answer to the dilemma I originally attempted to tackle by forking The Axx. If you come to my site in search of workflows to automate your iOS devices, now you can press a single button and scroll through only articles on this subject. If you are not currently interested in automation articles, but wish to read the “normal” blog posts that I write on technology in general, you can filter out the automation articles just as easily. I was also finally able to implement the Mint site tracking that I wanted, and rid myself of the ugly and confusing UI of Google Analytics. Finally, I built some custom share sheets to make sharing my posts on social networks or adding them to a read-it-later service possible directly from the site with just two taps.

Beyond the aforementioned changes, I also spent a significant amount of time writing my longest and most complex python script yet. This script, written entirely in Pythonista, fully automates the process of posting to Unapologetic. I can now write up a post in markdown from any text editor I want to use, then use the open in menu to send the text to Pythonista. Pythonista recieves the text and automatically (via the awesome new ability to script the open in functionality in Pythonista 1.4) runs the script to post to Unapologetic. This script applies the code for my custom footnotes and images, converts the rest of the markdown to html, appends and prepends the necessary code that wraps each of my posts, then uses the Pythonista ftplib module to upload the permalink file and the partial file (to be included in the home page) to their proper places on my server. Finally, it inserts the proper code to include the partial file in my index.shtml file, and inserts the proper code to my rss.xml file to finish everything off. This process literally could not be done manually from my iPad without this script, and to do it manually on my Mac is incredibly time consuming and prone to error. Now the entire workflow is done in less than five seconds, with absolutely no manual input from me after sending the post via an open in menu. I will write about the script in more detail in the coming weeks, and probably give access to most of the code for anyone interested in using something similar for their own website. For now, suffice it to say that my love and respect for Pythonista has no bounds, as this app has finally allowed me to return to doing all of my work solely from my iPad, an ability which I lost when starting Unapologetic, and am now very pleased to regain.

The Future

While there are still a few tweaks I may make to Unapologetic in the coming months (▼)(▲)Chiefly, I plan to make changes to the mobile version of the new share sheets to give options to run actions on the data they send via Drafts, Editorial, or Launch Center Pro. If you have any ideas on cool automation-related options I could implement in the share sheets that would be useful to you if you wanted to share my posts, please contact me. I want to make my share sheets as powerful as possible., mostly the site is solidly in the condition that I plan to keep it in for the foreseeable future. This means that I can stop coding and get back to writing posts, something I've been looking forward to for the last few weeks as I've watched quite a few subjects float by which I would have loved to join in the conversations on. I love writing for this website, and I can't wait to be back in the game. I hope you'll enjoy reading my posts as much as I'm going to enjoy writing them.

I love seeing innovative new ways in which companies are integrating with modern day services such as Twitter. The latest of these is a new initiative by Starbucks called Tweet a Coffee. Tweet a Coffee is a beautifully simple service. All you have to do is send out a tweet with the format “@tweetacoffee to @[friend's username]”, and your friend is automatically sent a $5 Starbucks gift card. That's it. You can also optionally add more to the end of your tweet as some sort of message to your friend. So long as the tweet begins in the exact format shown above, the rest of the Tweet's contents can be anything. Once your tweet has been sent, the tweetacoffee Twitter account will recognize it and @mention you and your friend, confirming the transaction and including a link to redeem the gift card.

The initial setup of Tweet a Coffee was easy and quick. I already have a Starbucks account set up, as I go to my local Starbucks almost every day to work. My Gold Card is linked to my Visa card, so that was ready to go as well. Tweet a Coffee prompted me to log into my Starbucks account, then to log into my Twitter account to link the two. After that, the service automatically pulled my card information and presented me with a box in the web view that was set up in the proper format to tweet a coffee. I went ahead and filled in the box, and moments later a free coffee was on its way to my friend Kelly.

If you don't have a Starbucks account, or don't have a credit/debit card linked to it, your initial set up will probably take slightly longer than the few seconds that mine did, but either way, once it's done it's done. If I want to tweet any more coffees in the future, I don't need to go through the web view, but can simply compose the tweet straight from Tweetbot from my linked Twitter account.

I was concerned when I first saw the service of the possibility of others stealing the coffees that I tweeted to my friends. Tweets are public, after all. I can't say for certain exactly how the process goes, as no one has tweeted me any coffees yet for me to try redeeming one myself, but when I clicked on the link that Tweetacoffee sent to my friend, the webpage that it directed me to included this text:

Someone sent you a Starbucks eGift through Twitter. We want to make sure that perfect cup ends up in your hands, not someone it wasn’t intended for.

Clicking the link beneath this sentence brought me to another Twitter authentication page, so presumably after authenticating yourself as the true recipient for the coffee, you will be able to redeem the gift card. Being able to trust that your tweeted coffee is going to the right place is the most important part of the process, and I see no reason anyone would be able to circumvent this authentication system.

I'm excited to see where Tweet a Coffee goes. It seems like an awesome new way to deal with things like owing your friends coffee, or sending someone a quick gift if they are sad or if it is their birthday. The simplicity of the system is extraordinary, and I think that Tweet a Coffee has potential to be a huge hit among average consumers. If you're curious about Tweet a Coffee, they're even doing a promotion in which the first 100,000 people to tweet coffees will receive a $5 Starbucks gift card themselves. Basically this means that you are giving coffee to someone absolutely for free. I can't be certain how many of these have been taken, but the Tweet a Coffee Twitter account has posted 23,479 times at the time of this writing, so I would assume it is somewhere around that number. Act quickly and you can try the service out like I have without wasting a dime, and give a friend some cheer as well.

Tweet a Coffee is a really cool idea, and I hope that more companies start taking advantage of Twitter or other social platforms to create their own innovative and useful new ways to interact with friends and followers. Currently the service is only supported in the US, but presumably they will expand into more regions if it is successful here. If you are in the US, you should check out Tweet a Coffee at its Twitter account or on its page on the Starbucks website.

Today marks the release of version 2.0 of Flexibits’ amazing iOS calendar app Fantastical. Fantastical 2.0 is not an absolute redesign. It keeps the app fundamentally the same, but definitely moves it away from the older iOS 6 style UI by flattening out the title bar and brightening up the colors. There is a new Light Theme as well, which I love. The main view is almost unchanged from the original version, but the Day Ticker now smartly starts at the first block, displaying four more days ahead of it instead of wasting space being in the center and leaving two days behind. Pulling down on the Day Ticker still reveals the full month calendar, which is unchanged. The Fantastical icon was made a little bit better than the old one by brightening up the colors and removing the ugly brownish calendar squares, but they still did not remove the simulated page curl in the bottom corner, which I continue to dislike. Admittedly though, I’m extremely picky about app icons, so you may find it perfectly acceptable.

The most notable addition to the new Fantastical is support for Reminders. Your reminders and calendar events are now all laid out together in the main view. I love anything that increases my day to day efficiency, and this new integration allows me to no longer need to open an extra app dedicated to reminders. Furthermore, Fantastical now supports adding reminders through its incredible natural language parsing engine, meaning I no longer need to deal with the terrible date picker in the Reminders app to set up a reminder for a specific day.

Over at The Axx, I’ve created two actions to speed up the process of adding events or reminders to Fantastical by using Drafts or Launch Center Pro. I’m particularly looking forward to now being able to type out a list of reminders, since I often add more than one at a time, and parse each of them, one by one, through Fantastical automatically. This has always been useful for adding events as well, but I find myself adding multiple reminders far more often than I add multiple events. You can get the Parse In Fantastical action, the one for parsing events, here, and the Parse Reminders In Fantastical action here. Keep in mind that parsing multiple events or reminders starting from Launch Center Pro will require a Pythonista script to break them up and format them correctly for Drafts to run the necessary actions (the script is available at the same link as well). If you start in Drafts, no script is needed.

Fantastical is a great update to my favorite event (and now reminder) parser. I still prefer Logacal for actually viewing my upcoming events, but I never add a single calendar event except through Fantastical, as no other app comes remotely close to besting the ease and accuracy of Fantastical parsing. You can get Fantastical 2 on the App Store for $2.99.

The Parse Reminders In Fantastical Action takes a draft (or Launch Center Pro prompt) and sends it to Fantastical to be parsed, but prepends whatever is sent with “Todo” so that Fantastical will parse it as a reminder. You can parse a single reminder or multiple reminders in a list using the same action.

Drafts

If you want to parse a list of reminders, 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 Parse In Fantastical Action

Launch Center Pro

In Launch Center Pro, each line is set up as a new event, so do not leave a blank line between events. The LCP prompt is set up as [prompt-list]. This prompt replaces newlines with commas, which is why we require a Pythonista script to change the comma separated events sent from Launch Center into their own individual lines, then sends those to Drafts and run the Parse In Fantastical action to parse them one by one. If you don’t have Pythonista, or don’t want to have to run a script each time you add a single event, Launch Center Pro has a Fantastical action to import a single event which you can find in the Action Composer. If you want to be able to parse multiple events, use this one.

Launch Center Pro Action:

Direct Import Link for Parse Reminders Action

Pythonista Script:

Make sure to name your script “Parse Reminders” or change your LCP action to match if you choose to name it something else.

import webbrowser
import urllib
import sys

reminders = sys.argv[1]
i = 0
while i < len(reminders):
    if reminders[i] == ',':
        reminders = reminders[0:i] + '\n\n' + reminders[i+1:len(reminders)]
    i += 1

reminders = reminders.encode('utf-8')
reminders = urllib.quote(reminders, safe='')

base = 'drafts://x-callback-url/create?text=' + reminders + '&action=Parse%20Reminders%20In%20Fantastical'


webbrowser.open(base)