Monthly Archives: October 2017

What makes you love or hate a smartphone?

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.

Thoughts on Android and iOS UI evolution

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: The iPad as main computer for programming

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.

SwiftoDo Development Notes, October 2017

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.

The Essential Phone

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.

Contexts in Getting Things Done and todo.txt

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.

Three ways to create nested projects in todo.txt

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.