Tag Archives: performance

Slow transitions in watchOS

Much has been made of the Apple Watch not being fast enough. It’s too slow for full iPhone-like apps, of course, but that doesn’t bother me because I think the watch is pretty great at its core features. But I’ve noticed that it’s slow even for some of the simple stuff, and I don’t think this can be blamed on hardware alone.

Take notifications, for example. There are several distinct steps to notifications after you receive one:

  • Tapping a notification.
  • Waiting for it to load, which is an animated transition.
  • Optionally scrolling to the bottom to read it all.
  • Actually tapping Dismiss to get rid of it.

There’s a tiny lag between all of these. I frequently can’t scroll right away, as if it’s not responsive until the animation completes. The Dismiss button also doesn’t seem to be enabled immediately, requiring a 2nd tap before it “clicks”.

I bet these are solvable with a software update. Shorter animated transitions or pre-loading notification text might go a long way to improve the experience.

Apple Watch is slow… for now

Dan Moren wrote an essay for Six Colors last week about why slowness is such a problem for the Apple Watch:

“The stale data and the lack of speed means that either you have to stare at your Watch for several seconds and hope the data updates; or tap on the complication to load the Watch app, which as we all know takes a good long while as well; or simply give up and pull out your phone. […] It’s not just that the Apple Watch is slow; it’s that it’s slow while promising to be faster.”

Both Dan and Jason Snell followed up on this topic in the latest Six Colors subscriber podcast. The problem, they recognized, is that the first Apple Watch tried to do too much. Apple should instead focus on a few core features and make them fast.

Which features? I still use the Apple Watch every single day, and I use it for just three things: telling the time, tracking fitness (including reminding me to stand up), and glancing at notifications.

Some people have stopped wearing their watch every day. Again, that’s fine. Curtis Herbert was falling into that category, until he went snowboarding with friends and realized how useful the Apple Watch is when you can’t get to your phone or tap buttons. In an article about the snowboarding trip, Curtis says the Apple Watch’s problems are solvable in future versions:

“Siri on the Watch will get faster. The battery situation will improve. The Watch as a whole will get faster. We’re spoiled by iPhone speeds and sometimes forget just how long it took us to get there, and the crap we dealt with until then.”

I’m not worried about the future of the watch either. Our early expectations were much too high — in contrast with the first iPhone, which exceeded all hopes because it was seemingly from the future already — and it will take a couple more years to catch up to where we’d all like the watch to be. In the meantime, the watch is useful today, even slow-ish.

Fancy-pants productivity

There are a few things in this post by “Ryan Norbauer”:http://notrocketsurgery.com/articles/2008/02/26/mention-in-wired-piece-on-37signals (via 37signals) that bother me. One is this idea that “code is meant to be read by humans first and computers only secondarily”. I understand what he is getting at, but even though I respect new advances in productivity, we have to be very careful to keep our core priorities. There’s a word for when the balance shifts away from the user and more to us as programmers: selfishness.

Imagine two programs: one is ugly and hard to read, but it compiles and is bug-free; the other is beautiful and readable, and it also compiles and is bug-free. To the user they are identical. They both succeed.

Now take those two and give them both identical beauty and readability, but accidentally break one so that it either does not compile or runs so horribly buggy and slow that it is useless to everyone. Writing code for other programmers to read isn’t enough. You have to start with code that works before you get all fancy-pants.

This growing trend to raise beautiful code and programmer productivity above the performance or functionality of the final product is dangerous. The final product is what counts. Not how you build it, but what you’ve built: how it scales, how it performs, how it solves a particular problem.

And sure, there are many times when I write slow, lazy code that doesn’t work well. But that’s a compromise you make when you have to meet a deadline, or because you aren’t sure how to optimize yet, not because you start out by deprecating user experience. If you believe Ryan, it sounds like there is a whole “movement” of programmers who toss any potential performance achievements out the window before they even get started.

You can say that great products are complex, and so you need to focus attention on how the software is built and maintained. That is true. When I ported a large application from Carbon to Cocoa a few years ago I made the decision to do so because of future productivity.

You can say that happy programmers create high-quality products. That is also true. When I am feeling most productive I am usually enjoying myself because the work environment I’m in is encouraging.

But don’t put the practice of software development above the actual result, because to do so means you care more about writing code than solving problems.