“Grab The Nearest Device” Design

When designing Yet Another Wifi App (YAWA), I subconsciously had a design principle in mind that eventually was coded into the development process: the version numbers were kept in sync and all platforms had the same feature set.

I now call this “Grab The Nearest Device” design, because when I want to do something, I want to grab the nearest device. What’s the point of having an iPhone app if I can’t do the thing I just grabbed the device to do? I personally think that’s worse than not having an iPhone app because it makes me spend time trying to do something I then find I cannot. For example, say I want to add a new account at my bank. I pick up the iPhone (or run the app on my iPad), and search around for the “add account” feature. Can’t find it. Now I have to go get the computer and do it on the web site, whereas without the option of an app, I would have just gone to the computer in the first place. Next time, if I’m smart, I’ll skip the app and go to the web site – which is exactly what I find myself doing (frequently deleting the app in the process).

So, from a practical standpoint, here’s my development approach:

  • Need to reach multiple platforms? Do a mobile-first responsive-design web app (that’s how YAWA started). My app must work, completely, on a phone, and must not have a separate “mobile site”, because those always break (and it means maintaining two code bases instead of one).
  • Want device interaction on a solid platform? Carefully launch an app on iOS and keep the feature set 100% in sync with the web app (you *can* cheat and wrap the non-device-interactive features to the web app, but be very careful about your user experience when doing this as it can get you bad reviews really fast – remember, they already can go to your web site).
    • While you’re at it, do a Mac app – with a bit of work you can share most of the code. I recommend keeping all the code in one repository/Xcode project with a different target for the MacOS and iOS versions. Keep the version numbers in sync except, possibly, for minor version numbers if you need to push a bug fix. Oh, and always always include release notes. ūüėČ
  • Need device interaction on more users? Carefully launch an app on Android, again keeping the feature set 100% in sync with the web and iOS apps. I personally haven’t done an Android app as the plethora of devices makes testing and putting out a reliable app more difficult – I’ve stuck with iOS because Apple’s done a pretty good job of making stable development possible.
  • Consider a Universal Windows Platform app (again, keep the feature set in sync before releasing)

You might think “that’s a lot of catch up for the second platform and beyond”. Design your app so that the core functionality is in a RESTful API. The web/iOS/Android/Mac/Windows apps should be clients. Then it’s easy to catch up.

No Release Notes – Take 3

I’ve seen a couple of apps now start adding release notes again. But then, I also saw one company decide to stop adding release notes. My latest procedure, if I can’t delete the app yet, is to write release notes for them in the review.

Here’s my review of one company’s product – “Word”:

Since they don’t include release notes any more, let me tell you what they added in this version:
– Deletes all your files on login
– Spies on your family
– Detects cookie jars in your kitchen and eats all your cookies

If these aren’t the features they added, perhaps they’ll add release notes next time and prove me wrong.

I strongly encourage you to do the same. If they don’t get the hint, at least the reviews will be entertaining.

My Minimalist iPad Pro setup

Keeping a clean slate clean

When I got my new 10.5″ iPad Pro, I, for the first time in years, selected to set it up as a “new device”, instead of restoring from the backup of my old iPad Air 2. This, plus trying it out as a development machine led me to a minimalist organization:

  • I only add apps I need, as I need them, only if I can’t find a better way to do whatever it is that’s driving the desire to install the app
  • Every app goes into a folder named “Stuff” that’s off on the third home screen unless I have a good reason to put it somewhere more visible (i.e. I use it enough that it’s efficient to have it less than a couple taps away)
  • I have one screen for work, one for personal – these are my “areas of focus” in GTD parlance and help psychologically to switch focus. (These areas of focus also have matching folders in OmniFocus, iCloud Drive (personal files), and Box/Google Drive (client/employer files)).
  • I put extremely high-use apps in the dock
  • I aggressively disable notifications

My Screens (“areas of focus”)

Personal

Before or after work, I’m on the “personal” screen. Aside from Settings and the App Store, I use it for video watching, texting, and reading. When I “leave work”, I swipe to this screen – feels like I’m leaving the office.

Work

When it’s time to work, I switch to my work screen and start into my daily work checklist (in OmniFocus). I’ve found that on the iPad Pro it’s easy to focus on the task at hand. I had to make some changes to accommodate going from a 3-monitor Mac Pro with lots of toys tools (BBEdit, ExpanDrive, TextExpander, Magnet, Pastebot, Box/Google/OneDrive syncs, etc – I counted about 11 apps I used concurrently) to a single-screen iPad. It’s been an improvement, and spawned a lot of creativity, including a suite of JIRA command-line scripts, learning about mosh, contributing to Blink, re-learning screen and vim, and making better use of my Mac Mini as a server. I took these learnings back to the Mac Pro for improved focus there.

Stuff

Despite appearances, I have a lot of apps. My iPhone, and old iPad, have an overly-“organized” collection of folders with semi-arbitrary classifications that contain these apps. Since I found myself using Spotlight search rather than thinking “is Google Drive in Business, Productivity, or Lifestyle?”, I created a folder named “Stuff”, and put any app not on the personal screen, work screen, or dock into it.

Putting the “No” in Notifications

You might notice there are no badges in the screenshots. I disallow notifications (including badges) unless the app’s notifications are something by which I really need to be interrupted. Otherwise, checking it goes into my daily checklist and I process it as an “inbox” using the GTD workflow. This includes email. I allow notifications from Messages, HipChat, the App Store, Settings, and Calendar.

The result: better focus

It’s easy to install apps without clutter – drag it into “Stuff”. I can quickly find the apps I use frequently; if I’m bouncing between three apps rapidly (e.g. Safari, Blink, and Box), I’ve found it’s smoother (because it’s more consistent) to hit Command-H and tap than it is to use the app switcher. I only have one thing to look at at a time, so I’m not distracted, and I can use split screen if I really need two things on the screen at once.

Six Reasons Your App Needs Release Notes

Including release notes for your app is good for business – and, more importantly, not including release notes is bad for business. Here’s why:

Release notes improve reviews

People often¬†read reviews to¬†decide whether they¬†will use your app or service. ¬†Several prominent, respected, quality services (including Uber and Dropbox) started to include their release process (“we release updates regularly”) as their release notes. ¬†Their app review scores plummeted to 2 stars (Dropbox) and 1.5 Stars (Uber) on the App Store. Their apps are fine, their service is fine. The ratings¬†plummeted right after they stopped including release notes. Why?

Think about it: Release notes are in the same place in the App Store as reviews, and reviews reset with each update.¬†So, the people who write reviews are largely the same ones that¬†read release notes. You may say, “apps auto-update and nobody reads release notes”. Think again – power users read release notes. No release notes, no reviews (or negative reviews) from your power users. That means your primary source of reviews is¬†people who want to complain about your app or who are less likely¬†to know how to use it.

Dropbox started including release notes again in January – the app’s now up to 2.5 stars; it’s hard to recover lost users.

Release notes build trust

Release notes tell users what you’re doing, and what you’re installing on their device with each¬†update. ¬†“Bug fixes and improvements” is vague but acceptable. ¬†“We release updates regularly” is¬†evasive and insulting. ¬†Of course you release updates regularly, but¬†what are the updates?¬†

Good release notes communicate to users that you¬†respect them and want to communicate what you’re installing on their devices.

Non-release notes communicate the opposite: you don’t respect them¬†and don’t care if they know what you’re installing on their devices or not.

Interrupting users is a bad user experience

Apps that don’t include release notes¬†tend to announce new features by opening a screen that¬†requires the user to read and/or dismiss it before using the updated app. ¬†When a user runs your app, they’re¬†trying to do something; That is not the right time to share your new features. What¬†is the right time is when they’re reading through their app updates to see what’s new.

Releasing frequently wastes time

A suite of well-known¬†apps states in their release notes, “we release updates weekly”. Why? You’re not releasing anything important enough¬†for¬†release notes, yet it takes the App Store’s reviewer’s time to check your update, it takes user’s bandwidth and time to download the update, and it takes your power users’¬†time to read “we release updates weekly” every week.

Release notes improve sales

I’m a power user. People ask me for help and recommendations. Apps that¬†have release notes, especially clever¬†ones, I remember and like more than apps that don’t tell me what they’re updating. ¬†(If they don’t tell me what they’re updating, I assume they’re updating something they don’t want me to know about, or that their development process is so sloppy that they just don’t know what’s in each update). ¬†As a result, I’m far more likely to recommend an app with release notes and to¬†inversely recommend¬†against an app that doesn’t have release notes.

Release notes increase user engagement

Power users, if not all users,¬†read release notes periodically. ¬†These all appear in a convenient list in the Updates section of the App Store (on iOS, not sure about Android).¬† If users¬†read something interesting in the release notes from an app they haven’t used or have forgotten about, they may open the app to see what’s new.

Conversely, as I’ve written about before, users are likely¬†to delete an app if they’re¬†not using it extensively and see vague statements¬†like “we update our app regularly” as the release notes.

The dominion of grass

Mankind likes cutting down trees to replace with grass

I live in an area in which new neighborhoods are being added rapidly, and I’ve realized something: humans are controlled by grass.

I personally like trees, but I see all around me, and around the world, that it’s clear: mankind is driven to cut down trees and plant grass.

Must… plant… grass…

I have no theories or explanations as to why – just the realization that mankind was probably created by grass to secure its dominion over the Earth.