I made a batch of Christmas cookies tonight with my daughter. Such fun! She pressed chocolate chips on top of sugar cookies that we rolled out together and cut—about 100 chips per cookie, I think.

A long lunch with the family was a great way to complete my work week.

So much of all programming, and really all work in general, is developing a common vocabulary, and after that, common goals. That is most of the work in a lot of the projects I work on.

I am up too late. What exactly is happening right now? 🙃

According to Dark Sky, a Christmas morning snowstorm may interfere with my holday travel plans. I am crossing my fingers that it doesn’t happen.

I’m relieved to have finished all my billable work for the week already. It was a tough week, and thankfully it is starting to wind down now. I am looking forward to a holiday break next week.

I wonder how many people still have to use VBA for Excel and Access automation at work, like I do. Googling for Office VBA how-tos feels like jumping in a time machine and going back 10 or 20 years. It is disappointing that Microsoft never added C#/.NET support to Office, but it is understandable.

I started a micro blog at mjdescy.micro.blog this week. It is not to replace this blog, but to supplement it with a more frequently updated stream of short comments and asides about my life, or about news items that directly affect my life in some way. I want it to be like Twitter was for me back when I first joined it: a stream of consciousness, and a window into my life. My plan is to keep this blog (my macro-blog?) free of micro blog posts and life blogging, and more focused on longer articles, bigger ideas, and more complete thoughts—as it has been from the very start.

I spent some time this evening starting to code something new for work in C#: a tool for comparing actual drug formularies to required ones. It should be a fun little project.

Twitter is abuzz about UIKit, perhaps, going to the Mac late next year. We’ll see. I would love to code a new version of my todo.txt app, SwiftoDo Desktop, in UIKit rather than AppKit. The different table view model is a big factor in that, though UIKit’s window and split view controls are, of course, different, too. WWDC will be especially interesting next year.

It’s the last work week of the year, and the busiest I’ve had in about six months. I had to work late tonight. (I’m still working, in fact.) It’s making me think of this bleak article I read earlier this evening: eand.co/what-do-y…

I’m happy to join the micro.blog community today!

Drafts is a tinkerer’s DIY dream of a text editor. It nails the basics, and allows you to customize its editor and its tag and folder system to fit your specific needs—it just takes a little time (and, maybe, some JavaScript skills, for some things) to do so.

Drafts is where text begins

Drafts, by Agile Tortoise, isn’t exactly an unknown app. On the contrary, it is one of the crown jewels of the iOS platform. It is one of the few apps with an in-app purchase tip jar that I actually threw money in—a few times, actually. Drafts makes my life simpler, in little ways, every day. Like one of my other favorite writing apps, Ulysses, it is a pleasure to use.

Drafts is primarily meant for quick text entry, and then pushing that text to another app for processing or storage. For example, I type most calendar entries and Google searches in Drafts (which is in my home screen toolbar) and, in two taps, open them for processing in Fantastical or Safari (which are not in my toolbar). Drafts 4, which has been out quite a while now, expands on that basic idea, and delivers a very useful utility and a top-notch text editor.

Not just for automation—for writing!

Drafts is already well known for its automation capabilities. It is great for drafting a tweet and posting it to Twitter (either natively or via another app), or for writing out a calendar entry and pushing it to Fantastical or Calendars 5 for parsing. What it is not well known for—but should be—is that it is the most customizable text editor on iOS. Editorial has long held that crown, thanks to its its support of snippets and extensibility with Python scripts. Drafts, however, outdoes Editorial when it comes to customizing the editor itself, which has a profound effect on writing experience.

In Drafts, actions can change the text your are writing, send some or all of it to another app, turn on/off night mode within the app, and so on. You can download actions from the developer’s extensive library, of, if you are a bit of a programmer, you can them yourself in JavaScript, from within the app. You can assign these actions to the main menu, which is accessible from the top-right icon, or from a swipe to the left. That’s the basic stuff. You can also assign these actions to a custom toolbar that is displayed over the keyboard. Even better, for hardware keyboard users, you can assign your own hardware keyboard shortcuts to these actions, too. No other iOS app that I use does this!

I use Drafts on my iPad primarily for writing notes, such as when I get a phone call or am in a meeting. I use my custom toolbar buttons to input today’s date, paste text, format headings and lists in Markdown, send various lines (text selections) to my todo.txt file (via Dropbox), and so on. At the end of my writing session, I send the entire note to Dropbox for storage.

Notes don’t have to be exported, however. They can stay in Drafts and sync to all your other iOS devices via iCloud. You can also organize them there. There are three basic folders—Inbox, Archive, and Trash—to put notes into. You can flag notes for future retrieval, and filter them them by folder, flag status, and keywords (search terms within the note text) into custom “folders” or saved searches as well. I have not switched over to using Drafts as a full-fledged notes app (most of my drafts get automatically deleted after 30 days in the Trash folder), but I am thinking about it.

Drafts in the future

Drafts 4 has been around for a while now. Drafts 5 is coming, someday, with even more features: TaskPaper editing is a feature that I am looking forward to. I expect the pricing model to change from paid upfront to a subscription; I will be happy to pay for it, as a valuable companion to Ulysses for writing, and a valuable sidekick to practically every other app in the iOS ecosystem.

I love Twitter. So much information and commentary is shared there, so quickly, that it is a vital source for “what is going on on the Internet today”. At the same time, I hate Twitter, for all the bad behavior performed on the platform that Twitter, the company, tolerates. I’m not alone. A lot of people I follow feel the same way. I see tweets like this almost every day:

Brad DeLong: “I wish there was a network like twitter, but not, you know, actually Twitter”

 

The folks at @twitter are spineless cowards.

I wish there was a network like twitter, but not, you know, actually twitter

— Dave DeLong (@davedelong) November 30, 2017

The thing is, practically since Twitter’s inception, alternatives did exist. I know. I used them: Identi.ca, StatusNet (the successor to Identi.ca), Pump.io (the successor to StatusNet), and App.net (a for-fee Twitter that got a lot of press but not so many users). And, I abandoned them and went back to Twitter, despite its flaws. So did everybody else.

Why is Twitter so sticky, and nothing else is?

What makes Twitter is valuable not what it does—microblogging is relatively easy to implement these days—but who is on it: Famous people! Intellectuals! Politicians! Journalists! These people and many more are not only publishing there, but reading there, too. Communication with, and between, influential people there can be two-way, and is usually in public, which is fascinating to read and unlike any other communications platform that had come before it. Twitter can amplify the voice of the non-famous and non-published people, too—the under-represented—which is often great.

Why is Twitter described as a cesspool?

Sometimes, though, amplifying under-represented voices is not great. Some voices are under-represented because they are malicious: Racists! Nazis! Liars! Sexist doxxers! Spammers! Russian bots! Malicious people have unique incentives to exploit and abuse a communications platform like Twitter. First, simply having a medium and a platform to spread their message is unique to them, because these people have been barred or banned elsewhere from spreading their message. Second, access to this new platform may be fleeting, because they could be banned there, too, for the same reasons they have been banned elsewhere. Third, people who want to spread malice are not the type of people who are concerned with preserving the health of the platform’s community, or the platform’s reputation in the wider world. Therefore, they can destroy the platform in the process of spreading their message.

Why can’t Twitter fix this?

The world is too complex to separate people, or Twitter users, into good and bad actors. What is unpopular or under-represented today may be celebrated tomorrow; it may be true and worth spreading today. Understandably, Twitter doesn’t want to choose who gets to speak on their platform. Therefore, they tolerate hate speech on their platform to a degree that makes some of their users angry. It puts the company in a difficult position when hate speech is broadcast (retweeted) by the President of the United States, as it was this week.

I understand Twitter’s problems as a company. It needs eyeballs on it to sell ads. Controversy on the platform, and the sheer number of active users (whether they are real people or bots), lead to greater traffic, greater revenue, and greater return on investment for their investors—at least in the short run. In the long run, however, poisonous speech on the platform poisons the platform.

What to do about it, as a Twitter user?

Basically, it is hard to see how, as users, we can improve Twitter. Twitter, the company, owns the platform. Consequently, it has the sole power to fix its flaws. Improvements to blocking and reporting abuse that Twitter has implemented have not satisfied the users who need them the most.

Moving away from Twitter entirely, onto another, similar platform, can work for small communities who primarily wish to communicate amongst themselves. It is unlikely, however, that a critical mass of influential users—the celebrities, journalists, etc., who make the platform valuable—will move to a different platform at this point. Without those users, another platform, however superior from a technical or community management standpoint, would not have as much value.

As a Twitter user, you really have two choices now: live with the abusive users, and report and block them as well as you can; or, if Twitter abuse is bothering you enough (or worse, threatening to your safety), stop using Twitter entirely. That is a sad conclusion to make, but I think it is realistic. Twitter’s ad-based model, need to generate both traffic and return on investment to satisfy its shareholders are, in the short run, at odds with its stated goal to improve safety, and therefore community, on its platform.

Fortunately, there are other ways to write content on the internet for free, such as WordPress. The problem is, you may never achieve the same reach with these other platforms as you would with Twitter. That is why I am sticking with Twitter myself. From a moralistic point of view, I would love to ditch it for something else. Despite that feeling, I get enough value from Twitter to keep using it, despite the sick-to-my-stomach feeling the Twitterverse gives me some days.

I learned about the Ghost blogging platform today. It looks awesome, especially with its simplified feature set (just what I need, nothing else), strict adherence to Markdown for writing, well-designed multi-platform front-end applications, and so on.

Mostly, Ghost’s speed impresses me. I hate how slow WordPress (the software that powers this blog) is compared to, say, a static website or a Jeckyll blog. I love fast-loading websites, and went out of my way to create static sites for 1000umbrellas.com and plaintext-productivity.net for that very reason.

Unfortunately, I doubt I will ever use Ghost. I am very dedicated to Ulysses as a writing tool, and Ulysses does not publish directly to Ghost. It publishes directly to WordPress, which is the main reason why I use WordPress. (Sure, there are workarounds for publishing from Ulysses to Ghost, but nothing beats a one-step solution.) WordPress is also ubiquitous, making it very cheap and easy to self-host.

I could pay more for faster WordPress hosting, but, considering how few readers I have, I can’t justify the additional expense. So, for the foreseeable future, I will enjoy easy publishing to WordPress via Ulysses, extremely cheap hosting expenses, and my readers will have to wait a second or two for my blog to load. I hope nobody else minds.

At the end of last year, I quit using RSS. It was a big step for me. I had been using RSS practically since it first became available. My first RSS reader was the Sage plugin for FireFox, which I started using in 2004. I subscribed to Slate, LifeHacker, a couple other professional publications, and a fairly large number of personal blogs, covering topics ranging from technology, economics, and personal finance to cooking and television shows. I was obsessive about skimming my feed many times a day, reading every headline, and often every article, of Slate and my favorite blogs.

I eventually dropped Sage for Google Reader, and used it, and later Feedly, as a back-end to whatever smartphone RSS reader I was using. For years I checked my feeds a dozen times a day, read a ton of articles (though not all of them, as I used to), and generally felt pretty happy with the experience.

Why I quit using RSS

I stuck with RSS long after I became a habitual Twitter user, long after I started to see articles linked to from Twitter before they hit my RSS reader, and long after most technology writers and podcasters started disparaging RSS as some antiquated technology that, like dial-up internet service, was hopelessly out of date.

Eventually, though, I quit using RSS—not because it was uncool, but because it was no longer making me happy. Like those writers and podcasters said, the basic need RSS fulfilled for me—keeping current, and entertained with fresh reading material—was being fulfilled by other services. Twitter did so more timely, and with more commentary from the writers. News aggregators, such as Apple News, did so with a slicker visual style. (I am emphatically not a regular Facebook user, so I miss out on whatever is going on there.)

I thought these services were more hip, modern, and fun than RSS. Most importantly, I thought they were keeping me more current. After all, for a long time, my RSS reader (the wonderful Reeder app for iOS) fed me the same articles that I had already seen on Twitter. Worse, it fed me five or six different publications’ takes on the same subject every day, which was interesting a few days of the year (such as when reviews of new Apple devices hit the streets), but was otherwise completely redundant.

What I missed without RSS

After a year RSS-free, I started to think something was missing. I was literally missing articles that I would like to read, especially those from bloggers I liked, such as Erica Sadun and John Gruber, because they would pass by in the timeline before I would see them. I was missing bloggers’ voices in general, because most of my Twitter list (like everybody’s, I’m sure) is heavily news related. I could keep up with what the New York Times and Washington Post are publishing each day pretty well; but what about what Manton Reece and Tyler Cowlin are publishing? Their voices were being buried in my Twitter feed by the daily (hourly?) news cycle.

Without RSS, I missed the spirit of the independent web: all those individuals and small publications who are sharing knowledge and expressing opinions that don’t fit into 140 characters, or even 280.

Back to RSS (and Atom, and JSON Feed)

After many months away from it, I realized that RSS wasn’t the problem—I was. I wasn’t using RSS in a way that made me happy. Worse, I supplanted it with Twitter, which both sucked up all my attention every day, and reduced my attention span for content to 140 characters (a length perfect for snipes and jabs and headlines, but insufficient for most cogent thoughts). Fortunately, RSS has not died since the rise of Twitter and Facebook. It has quietly remained a fundamental internet technology, undergirding nearly every online publishing platform. Many, many sites support it without advertising it the way they used to ten years ago. Luckily, any good client can find feeds using just the site URL.

Not only RSS is still there: my longstanding RSS software is still there, too. Like in 2013, I am using Reeder on iOS as a front end, and Feedly as a back end. Reeder has been around almost as long as the App Store. It is rarely updated, but it just works. It’s simplicity, elegance, and stability make it one of the finest apps on the platform. Feedly, the back end service that actually checks my feeds, is a free service that I basically never look at. I don’t use their website. I don’t use their app. I don’t really know or care how they make money off of me. It, like Reeder, is solid, stable, and just works.

Using RSS with a different perspective

After returning to my RSS reader after such a long break, I had thousands of unread items and dozens of subscriptions. I decided to start over, so I unsubscribed to all my feeds, and started thinking about what I really wanted to get out of RSS, and, in general, out of the Internet.

I decided to use RSS differently now. I no longer need it to drink the content firehose and keep current with the minute-by-minute news cycle; Twitter is available for that, for good or ill. Instead, RSS enables me to follow a few interesting voices on the Internet, read their actual, in-depth thoughts, and not miss anything they have to say.

To these ends, I no longer follow big media sites. Primarily, I follow blogs: real blogs, written by actual people, rather than published by massive organizations. I’m mostly following Apple-focused tech bloggers and Swift programmers, which reflects my favorite hobbies—but that’s just what I’m doing for now. Lastly, I’m not checking my RSS feeds a hundred times per day. I am checking only a one or two times per day, and often I don’t have any updates. Instead of adding more feeds, I just accept it now. Sometimes there’s nothing new to read, and that’s OK.

I’m happy with RSS again. All it took was figuring out what I really needed to get out of it, and taking control of how I used it. It’s a really great technology, no matter how passé or uncool it seems to be.

I love Ulysses.

This post on the Ulysses blog illustrates its value proposition. It is a minimalistic plaintext editor. It eschews common word processing features (such as rich text formatting) and some high-end “writing app” features (storyboarding, a character name generator, etc.) in favor of a stark, clean interface and generalized organizational tools (a unified library of “sheets” that can be organized in folders or with keywords).

In a way, its lack of features is its greatest feature. It focuses on the text, both from a writing standpoint and a publishing standpoint. That’s what writers should do—and want to do (really!). But writing is hard work. It requires incredible focus, and achieving and maintaining that focus is really hard. Just about anything is easier than writing most of the time. That’s why writers, famously, procrastinate. Sometimes, though, writers get into a flow state, just like software developers do, and any distraction will break that flow. App-induced distractions are particularly unwelcome. The worst offenders, ironically, tend to be features that promise to help make your writing process easier—especially if those features don’t exactly gel with what you are doing.

Ulysses gets that. Its feature set is intentionally uncomplicated and applicable to a broad base of writers. It hides some of its most powerful functionality, such as its awesome publishing features, until you actually need it. It doesn’t impose any system, workflow, or rules on you. Its simple system of sheets, folders, and keywords allows you to build your own organizational system that is specific to your projects—or, alternatively, to ignore organization until you absolutely need it. Most importantly, it puts the focus on the text, right where it needs to be.

The Essential Phone has been making some interesting moves in the market lately.

1. Essential dropped its asking price by $200.
2. Essential released their second monthly software update, which improved performance (smoother scrolling! faster camera app!) and added some gesture support to the fingerprint sensor on the back.
3. Essential is releasing new colors, starting with Pure White, which looks really good.

It has had a reputation amongst tech writers and podcasters as a market failure. This reputation was somewhat deserved. At launch, it had its share of problems. Its camera app was slow, unstable, and took inferior pictures. Some people (not me) experienced lag in the user interface, mostly micro-stutter while scrolling (a common Android defect). The speaker grill had a tendency to fall out. Reports circulated that only an embarrassingly low 5,000 units had been sold in the first few weeks.

Essential has almost completely fixed these problems. The camera app is faster and takes better photos. The user interface runs more smoothly than ever; micro-stutter is gone. I had the misfortune to have the speaker grill defect on my phone, but they RMA’d it within three days, and the new phone has a different grill design. I think the recent drop in sales price by $200, to a more reasonable $499, will probably make a huge difference in sales volume.

I feel heartened that they are working hard to solve their problems, and get their phone (which is pretty great) into more people’s hands. People are coming around—case in point, these articles:

• Essential Phone is the best deal in smartphones thanks to camera updates
• Essential Proves How Sensible Pricing and Software Updates Can Redeem a Failing Phone
• Essential Phone update adds fingerprint gestures, touch scrolling improvements, and more

I really like the Essential phone, and hope it can find a profitable place in the market for years to come.

I wonder this, as smartphones are maturing into what may be their final form: bezel-less slabs of glass with high-res screens, microphones, and sensors, that all look pretty much the same. The iPhone 8, for example, is the fourth generation of iPhone with the same basic form factor. A few years back, this would have been unheard of. A few years from now, though, I wouldn’t be surprised if there still is a “legacy” iPhone out there with this form factor, discounted several hundred dollars below what the iPhone X form-factor phone of the day will cost.

If all smartphones have the same basic shape, does it even matter which one you have? I think it does. You can still hate one phone and love another with the same case design. There are other things that matter, beyond the obvious distinction in operating system and/or Android skin. My experience with the iPhone 6S vs. the iPhone 7 is a case in point.

Nearly identical phones can be vastly different

Last September, I traded in my one-year-old iPhone 6S Plus for an iPhone 7 Plus, though Apple’s iPhone upgrade program. I hadn’t originally intended to do this. I had always kept my phones for two full years, and I chose the iPhone upgrade plan to get a nice monthly payment that also included AppleCare+.

The reason why I upgraded last year is that, after a year with it, I decided that I hated the iPhone 6S Plus. My 6S Plus was fine, and I never had any problems with the hardware or software, but I never really liked it, for several reasons. First, it was big, and I wasn’t used to big phones at that point. Second, it was ugly: the space gray aluminum finish was dull and drab. Third, it was ungainly: not only was it a large phone that strained my hand and my pockets, but its edges were smooth and slippery. Its Apple leather case was awful, too: it had mushy, hard to distinguish buttons, and its patina became slick and unpleasant after only a few months of wear. (Yes, I know the leather case is not the phone, but as it was an Apple product released alongside the phone, I think it is fair to include it in my assessment here.) The phone’s camera and software ecosystem were great, but it didn’t feel good in my hand, and that is crucial to how attached you can get to a handheld device.

While I grew to hate the iPhone 6S Plus, I quickly grew to love the iPhone 7 Plus. This surprised me, because the 7 Plus is basically the same phone. Sure, it has several major improvements—most notably, dual rear cameras and a much faster processor. Its minor improvements, however, contribute a lot more to my love for it. First, it looks great: the black finish is gorgeous and even blends seamlessly with Apple’s black leather case. Second, it feels great: I like the feel of the back much better, and the Apple leather case that came out with it has better quality leather, and clicky buttons on the sides. Its Taptic Engine, which provides force feedback for 3D Touch, the home button, and various user interface interactions, is absolutely amazing. It makes certain interactions, like scrolling picker views, 3D touching app icons, or pressing the home button, feel like you are interacting with actual, three-dimensional objects. It doesn’t vibrate as much as tap you with a reassuring, nearly soundless thud. The force feedback feels so good that it is almost addicting. It’s the kind of thing you would never think is important before you have it, but you don’t want to live without it once you do—like having heated seats in your car, for instance, or even the Apple Watch.

It isn’t just about the iPhone

I have the Essential Phone, now, too, which runs Android. I love it, too, though not as much as the iPhone. Why I love it, however, is a similar story to the one above, but it takes into account other manufacturers’ phones as well.

The Essential is one of a new breed of “bezel-less” phones. (These phones all still have bezels or notches or cutouts somewhere.) It is a smaller phone with a larger screen, much like the iPhone X, Pixel 2 XL, and Samsung Galaxy Note 8. Its lack of bezels make it smaller, and therefore easier to hold and pocket, than my iPhone 7 Plus, and other flagship phones of yesteryear.

Its glass screen and ceramic back make it like an impossibly smooth and cool piece of jet black soap. Its flat sides and smooth edges make it just grippy enough to feel secure in the hand, as opposed to slippery and droppable. Holding it, rather than using it, is the luxurious part of the experience. It feels just fantastic in the hand.

It doesn’t hurt that it has snappy performance as well—but you could get that from other phones as well. In fact, I vastly prefer it to the Samsung Galaxy phones and Pixel phones (the last generation, alas) that I’ve held. While those are the top Android phones in performance, hardware design, and features, I just don’t like them. It’s hard to put my finger on exactly why, but the materials and case design do not suit my tastes at all. They feel icky to me, in a way the Essential Phone never did.

The emotional connection

It isn’t 100% rational what makes a piece of technology suit you. It’s emotional. And sometimes the most subtle things—such as the color and feel of the materials, or the quality of the haptic feedback—can make you love a phone, or hate it.

Great haptic feedback is a major contributor to why the iPhone 7 Plus is my favorite phone. It feels great, and it feels alive when I touch it. I didn’t expect that feature to even matter to me, let along bind me to that particular model of phone. But it did. I don’t think most handset manufactures get that. After all, feeling is not a checklist feature.

I think Apple does get it, and little things like the Taptic Engine feeling so different than anything else are intentional parts of their industrial design and marketing strategies. Their industrial design and marketing teams have started (first, in my opinion, with the Apple Watch, and then with the iPhone 7), to really concentrate on what makes personal technology personal—that emotional connection you can have to your devices. And what they are doing is certainly working on me.

One of the Essential Phone’s core features is that it runs stock Android, rather than a flashy but slow and heavyweight skin like Samsung’s TouchWiz. Using this phone has been my chance to reacquaint myself with Android after a six year break, which was, in many ways, more interesting to me than testing out a phone with a cutting-edge, “bezel-less” design.

My last Android device was a Motorola Droid, running CyanogenMod’s version of Android Froyo. By the time I was able to upgrade to an iPhone 4S, in 2011, I wanted to throw the Droid against the wall. While it had lots of cool apps and was packed with features, it was so unreliable that I could barely make calls or take pictures with it any more. The iPhone, in comparison, seemed restrained and tasteful in design, fast and efficient in processing, and 100% reliable. What it lacked in customizability, it gained in simplicity and stability.

What happened to Android in the past six years?

Stock Android has changed less than I expected since my days running CyanogenMod on my Droid. When I unboxed the Essential phone, I was surprised right away that Google’s phone setup process was essentially unchanged since 2011. It worked well then, though, and it worked just as well today.

That same “it if ain’t broke, don’t fix it” attitude has been applied to be base Android OS features, too: the home screen, notification shade, app drawer, and so on were pretty much unchanged as well. Again, they are functional, and, unlike on iOS, replaceable by third party software; understandably, improving them must be a low priority for Google.

Android’s largest transformation since 2011, at least from a user’s perspective, is the introduction of Material Design. Google introduced Material Design in 2014 as the default design language on Android. It is, undoubtedly, an improvement over what had come before, but its principles are not universally applied, and don’t necessarily make apps easier to use in every case.

I don’t think Material Design has had a big effect on how Android apps are designed or used. Some indie developers never bothered to adopt it. Even on apps from big companies with large, talented, and nimble development teams, screen layouts are still dominated by hamburger buttons and slide-out menus, which leads to tedious navigation between parts of an app, and low discovery of key features. Also, sharing information between apps is still run through the same kind of share sheets used in 2011, which, ironically enough, can’t be customized as much as iOS share sheets can.

After a month or so of Android use, I concluded that Android runs more smoothly on high-end hardware than it did five years ago, but it is practically unchanged from a user experience perspective. As an iOS user, this is shocking, because iOS is completely different than it was in 2011.

Where has iOS been all this time?

Back when I used the Droid, Android was way ahead of Apple for many software features: the notification shade, quick settings on the notification shade, text selection, voice input, customizability, and, most of all, app extensibility (data sharing between apps, mostly) were way better on Android than on iOS. It would be fair to say that, in terms of user-facing features, iOS had a lot more ground to cover than Android did to improve certain aspects of user experience. My assessment now, with an Essential Phone and an iPhone 7 Plus at my disposal, is that Apple’s slow and steady advancement of iOS has allowed it to catch up to Android in all these areas, and exceed it in many of them.

The overall user interface design on iOS changed significantly in iOS 7, and has been refined and expanded upon in each iOS release since. Apple stole good user interface ideas from Android, such as the notification shade and the control center, but designed them differently and refined them each year, and implemented its own means of app extensibility in iOS 8, which has been slowly expanding in capabilities and usefulness year by year. An extensive number of indie developers’ embrace of x-callback-url for app extensibility has been a huge driver of inter-app communication and automation. App extensions, introduced by Apple in iOS 8, have matured into a cohesive ecosystem that does wonders for various workflows, especially those involving text and images. Apple’s Files app in iOS 11 allows third party storage providers, such as Dropbox, to have first-party-level integration with the OS and any apps that support the Files API. It is actually simple and seamless to use Dropbox with all sorts of iOS apps that were not written to support it. In this regard, Android is stuck in the same world as iOS 11 and earlier, where file service can be integrated, but each integration feels looser, more like a bolt-on feature or an afterthought.

It’s easy to think that iOS has been stagnant for many years because you still can’t arrange your app icons in arbitrary patterns on the screen, or change your default email app. If you can look beyond those customization points, you will see an enormous evolution in design and functionality on iOS, which is unmatched on the Android side.

Jannis Hermann’s blog post about developing full time on the iPad Pro is fantastic. I’ve heard about others using his approach: offload development tools to a server and connect to it using Mosh. I wish I could set something similar up for my programming hobby, but it wouldn’t apply very well to Xcode. Still, Jannis’s blog post inspires me to figure out a better way to update my non-Wordpress-based websites via my iPad, which is just something I haven’t tried yet.

As an iOS developer, my job is never done, even though my app, SwiftoDo, is internally simple and focused. There are always more features to add. There is competition in the App Store to worry about. There are third party libraries that deal with that break from time to time or have APIs change. Most of all, there is the regular drumbeat of regular iOS updates, which, frustratingly, can break standard UI controls and behaviors, and new hardware to support.

What I like about having my own iOS app is the act of creating something unique, something I actually use every day, and supporting other people who want to use it to. It is a lot of work, but it is also a lot of fun—except for migrating between Swift versions every year; that part I could do without, and hopefully the changes will be more minor as time goes on.

Right now I am trying to knock out several features that have been in development since this summer, and get it all done before Apple no longer supports builds from Xcode 8.3.3. I think, when I finally upgrade to Xcode 9 and do yet another Swift version upgrade of my code, I will drop support for iOS 9, and bump the minimum supported iOS version up to iOS 10.3, or maybe even iOS 11.0. I hate to do that, but support for the older SDK is probably causing me more trouble than it is worth at this point. Still, I don’t want to leave my iOS 9 users with an app that is broken or unstable in any way. That is why I have delayed dropping support so long now.

Early last month, I had the opportunity to acquire my first Android phone since the 2009 Motorola Droid: the Essential Phone. I got it in exchange for writing an Amazon review and a future tax liability, but it was more than a fair trade. I am impressed with the hardware, disappointed with the camera, and, honestly, not impressed enough with the Android ecosystem to switch from my iPhone 7.

I am making it a point to use it every day, though, mostly to satisfy my curiosity about Android, and partly because it’s a beautiful peace of hardware that feels great in the hand. While no one needs two smartphones, getting this one has satisfied my curiosity about modern Android software and “bezel-less” phone hardware.

I plan to write more about my thoughts on Android, and about what I learned from my experience with the Essential Phone, in the near future.

One of the great insights of the Getting Things Done (GTD) system is that tasks not only have projects, but contexts as well. A context is, basically, a thing or place or situation you need in order to do a task. Examples include: @home, @work, @phone, @computer, @errands, and so on. With projects and tasks, you can visualize your task list as a two-dimensional grid, with one row per project, and one column per context. This helps you determine what your next action should be. You can only do the tasks that are in the context you are currently in. That’s great, right?

What good is a context when I have everything at hand at all times?

Well…what I have found is that the typical set of contexts outlined in the “Getting Things Done” book are not really that useful to me. I only use my task list for work, so I’m always “@work”. I do all my work on a computer, which is portable, so I’m always “@computer”. I always have my mobile phone on me, so I’m always “@phone”. After diligently typing out these contexts in my todo.txt file and later ignoring them, for a long, long time, I realized that doing so was pointless. I only work in one context, so why bother to track it?

A foolish consistency is the hobgoblin of little minds

This was not immediately obvious to me because I was trying really hard to be a faithful GTD practitioner, and do everything that entails completely and correctly. When I realized that one of GTD’s key tools, the context, was useless to me, I felt lost. After rereading the “Getting Things Done” book, and trying even harder to commit to the system, I finally threw in the towel on contexts: I stopped using them entirely, for several years.

Doing so felt weird at first, and then liberating, like removing a little stumbling block from every task I wrote. I realized that following the system is not the important thing: getting my work done efficiently is the important thing. There was no point to keep adding contexts to tasks that did not need them.

Not using contexts in GTD

What I learned, obviously enough, is that not using contexts in GTD is fine. It doesn’t matter that it isn’t “pure” GTD. The system doesn’t matter; the results matter. If using contexts is just a minor drag on productivity, drop them and don’t give it a second thought.

Using contexts again, differently than before

After not using contexts for a few years, the nature of my work changed, and, as a consequence, I discovered new uses for them. My prior job entailed leading rather lengthy one-off audits, start to finish, with little commonality between them. My current job had me working mainly on data analytics procedures within over fifty similar audits, all performed over a several year period. Because of the highly structured nature of this work, and the tighter timeframes for producing deliverables, I sought to add more structure to my task list system. Contexts helped me do that.

The breakthrough for me was when I started using contexts to indicate phases of work (@planning, @development, @analysis, @reporting), and people I was working with (@Jo, @Susan, @Craig). These contexts had nothing to do with time, place, or equipment. Instead, they had to do with mental state (the type of thinking I had to do) and relationships with my coworkers. I am not always in the right mindset to perform a particular type of work (say, rigorous data analysis), and the people I am working with have different availability and expectations, so it is useful for me to keep track of those things in my task list.

Using projects and contexts with todo.txt

Todo.txt lets you manage your tasks using several axes: project and context, which tie directly to GTD concepts; and priority, which does not (though it is helpful to consider priority “A” your GTD “next action” indicator). While I have not come across any software that outputs your todo.txt file as a two-dimensional grid, pretty much all todo.txt apps have effective sorting and filtering capabilities. I filter and sort by todo.txt list on project and context numerous times throughout the day (mainly using SwiftoDo on my iPad), as I complete tasks and try to identify my next actions. Sorting and filtering on project and context, and diligently setting and resetting priorities, helps me stay productive and avoid letting things fall through the cracks every day.

The todo.txt format does not support nested projects, which is something outline-based formats such as TaskPaper do very well. Fortunately, nested projects can be faked in todo.txt in a few different ways:

1. Use two project tags, as in: write blog post +Blog +Plaintext
2. Use one project and one context tag, as in: write blog post +Blog @Plaintext
3. Combine the project and sub-project in the project tag, as in: write blog post +Blog-Plaintext

I have found option 3 to work best for me, for two reasons:

1. Multiple project tags can confound todo.txt applications’ sorting and filtering algorithms. It defeats the point of having nested-projects if you can't filter properly on them.
2. I use contexts either for broad, overarching categories of work (@planning, @coding, @testing) or people (@Dave, @Greg, @Dom), so they are off limits for other uses.

While the todo.txt format is not the best for planning hierarchical projects, it can be done with a simple workaround. Concatenation of the project and sub-project names is the best method for me.