Switching to iPhone for a bit

I’ve been a fan of Googles products ever since I switched from Alta Vista. So it felt like a natural fit to get an Android device back in the day when it was time for me to upgrade from my dumbphone, and I’ve been using an Android device ever since. I wrote about ecosystems a while ago, and the ecosystem is exactly what’s kept me there: you sign in to your phone with your Google account, and mail, calendar, notes, contacts and photos sync automatically. Also there’s a really great maps application.

In my day job I make web-apps that have to work on mobile first, and iOS is an important platform for me to know. Now I’ve used iOS for years — it’s the phone I bought for my wife and recommended to my dad. We also have an iPad, and I have used an iPhone for testing for years. I’m no stranger to how things work there. But I feel like something special happens when you make a conscious switch to the platform, make it your daily driver. Phones have become so utterly personal devices, they’re always with us and we invest ourselves in them. Unless I jump in fully, I have a feeling there’s some bit I’m missing.

So starting today I’m an iPhone user. No, I wouldn’t call this a switch — call it a “soak test”. I fully expect to switch back to Android — I’m actually eyeing a Moto X 2014. That is, unless the experience of investing myself fully in the iPhone is so compelling that I have no desire to go back, which is entirely possible. I won’t know unless I give it a proper test. Since I’m in the fortunate position to be able to make this switch, there’s no good reason not to. I’ll be using my white iPhone 5C testing device. I expect to be impressed by the camera. I expect to enjoy a jank-free fluidness of the OS, even if I expect to turn off extraneous animation. I’m curious how I’ll enjoy the homescreen and its lack of customizability compared to Android, and I can’t wait to see if the sliding keyboards in the App Store are as good as they are on Android. I should have some experiences to share on this blog in a month or so. Let me know any apps you want me to try!

Switching to iPhone for a bit

I’ve been a fan of Googles products ever since I switched from Alta Vista. So it felt like a natural fit to get an Android device back in the day when it was time for me to upgrade from my dumbphone, and I’ve been using an Android device ever since. I wrote about ecosystems a while ago, and the ecosystem is exactly what’s kept me there: you sign in to your phone with your Google account, and mail, calendar, notes, contacts and photos sync automatically. Also there’s a really great maps application.

In my day job I make web-apps that have to work on mobile first, and iOS is an important platform for me to know. Now I’ve used iOS for years — it’s the phone I bought for my wife and recommended to my dad. We also have an iPad, and I have used an iPhone for testing for years. I’m no stranger to how things work there. But I feel like something special happens when you make a conscious switch to the platform, make it your daily driver. Phones have become so utterly personal devices, they’re always with us and we invest ourselves in them. Unless I jump in fully, I have a feeling there’s some bit I’m missing.

So starting today I’m an iPhone user. No, I wouldn’t call this a switch — call it a “soak test”. I fully expect to switch back to Android — I’m actually eyeing a Moto X 2014. That is, unless the experience of investing myself fully in the iPhone is so compelling that I have no desire to go back, which is entirely possible. I won’t know unless I give it a proper test. Since I’m in the fortunate position to be able to make this switch, there’s no good reason not to. I’ll be using my white iPhone 5C testing device. I expect to be impressed by the camera. I expect to enjoy a jank-free fluidness of the OS, even if I expect to turn off extraneous animation. I’m curious how I’ll enjoy the homescreen and its lack of customizability compared to Android, and I can’t wait to see if the sliding keyboards in the App Store are as good as they are on Android. I should have some experiences to share on this blog in a month or so. Let me know any apps you want me to try!

Archive, Don’t Delete

I’m one of the lucky … actually I have no idea how many or few have Google Inbox. In any case, I was graciously sent an invite, and have been using it on the web and on my Android phone since then. I love almost everything about it. I particularly love the fact that Inbox seems to be able to divine what archetype an email has. Is it spam? Don’t show it to me. Is it travel-related? Bundle it up. Same with purchases, social network notifications, promos, etc. It even does a good job of prioritizing each bundle, and only showing notifications when it thinks it’s urgent — configurable of course. It’s pretty great.

I don’t love how hard it is to delete an item. You have to dive down deeply into an overflow menu on a particular email to find the “Trash” button. I wish it was more easily accessible — I don’t know man, I guess I’m a deleter. I remember buying a 320mb harddrive called “Bigfoot” because it was so humongous, but even then I had to manage my space in order to fit everything. So I can’t help but feel like this is a generational issue, and I’m now a relic of the past. It had to happen eventually, and I’m getting a really strong vibe that the ceremonial burial of the trash button was very much intentional. It’s behaviorism: teaching you not to delete, because archiving is faster and safer.

The crux of the Inbox app is the embracing of the idea that an email is a task. This is contrary to a very popular notion that you should very much separate those two paradigms as much as you can, so it’s very interesting to see Google leaning into it. Combined with their concept of “bundles”, I think it makes it work.

Let’s walk through it: it’s Monday morning and you just arrived at the office to open up your email. You received a couple of promos from Spotify and Amazon in one bundle, an unbundled email from mom, 9 bundled Facebook notifications, and two shipping notifications in a bundle. The one email worth looking at is immediately obvious, so you can either tap “Done” on the “Promos”, “Purchases” and “Social” bundles to end up with only the one email, or you can pin moms email and tap the “Sweep” button. Everything but the email that needs your attention is archived and marked “Done”, and it took seconds.

This is how Inbox is supposed to work. You archive tasks you’re done with, you don’t delete. If something important did happen to be in one of the tasks you quickly marked done, it’s still there, accessible via a quick search. If you get a lot of email, I really do believe that embracing Inbox will take away stress from your daily life. All it asks is that you let go of your desire to manage your archive. You have to accept that there are hundreds of useless Facebook notification emails in your archive, emails you’d previously delete. It’s okay, they’re out of sight, out of mind, and no you won’t run out of space because of them. Checking 9 boxes and then picking the delete button, as opposed to simply clicking one “Done” button — the time you spend adds up, and you need to let go.

I know this. I understand this. As a webdesigner myself, I think there are profound reasons for hiding the delete button. It’s about letting machines do the work for you, so you can do more important things instead, like spending time with your family. It’s the right thing to do. And I’m not quite ready for it yet. Can I have the trash button be a primary action again, please, Google?

Archive, Don't Delete

I’m one of the lucky … actually I have no idea how many or few have Google Inbox. In any case, I was graciously sent an invite, and have been using it on the web and on my Android phone since then. I love almost everything about it. I particularly love the fact that Inbox seems to be able to divine what archetype an email has. Is it spam? Don’t show it to me. Is it travel-related? Bundle it up. Same with purchases, social network notifications, promos, etc. It even does a good job of prioritizing each bundle, and only showing notifications when it thinks it’s urgent — configurable of course. It’s pretty great.

I don’t love how hard it is to delete an item. You have to dive down deeply into an overflow menu on a particular email to find the “Trash” button. I wish it was more easily accessible — I don’t know man, I guess I’m a deleter. I remember buying a 320mb harddrive called “Bigfoot” because it was so humongous, but even then I had to manage my space in order to fit everything. So I can’t help but feel like this is a generational issue, and I’m now a relic of the past. It had to happen eventually, and I’m getting a really strong vibe that the ceremonial burial of the trash button was very much intentional. It’s behaviorism: teaching you not to delete, because archiving is faster and safer.

The crux of the Inbox app is the embracing of the idea that an email is a task. This is contrary to a very popular notion that you should very much separate those two paradigms as much as you can, so it’s very interesting to see Google leaning into it. Combined with their concept of “bundles”, I think it makes it work.

Let’s walk through it: it’s Monday morning and you just arrived at the office to open up your email. You received a couple of promos from Spotify and Amazon in one bundle, an unbundled email from mom, 9 bundled Facebook notifications, and two shipping notifications in a bundle. The one email worth looking at is immediately obvious, so you can either tap “Done” on the “Promos”, “Purchases” and “Social” bundles to end up with only the one email, or you can pin moms email and tap the “Sweep” button. Everything but the email that needs your attention is archived and marked “Done”, and it took seconds.

This is how Inbox is supposed to work. You archive tasks you’re done with, you don’t delete. If something important did happen to be in one of the tasks you quickly marked done, it’s still there, accessible via a quick search. If you get a lot of email, I really do believe that embracing Inbox will take away stress from your daily life. All it asks is that you let go of your desire to manage your archive. You have to accept that there are hundreds of useless Facebook notification emails in your archive, emails you’d previously delete. It’s okay, they’re out of sight, out of mind, and no you won’t run out of space because of them. Checking 9 boxes and then picking the delete button, as opposed to simply clicking one “Done” button — the time you spend adds up, and you need to let go.

I know this. I understand this. As a webdesigner myself, I think there are profound reasons for hiding the delete button. It’s about letting machines do the work for you, so you can do more important things instead, like spending time with your family. It’s the right thing to do. And I’m not quite ready for it yet. Can I have the trash button be a primary action again, please, Google?

The One Platform Is Dead

I used to strongly believe the future of apps would be rooted in web-technologies such as HTML5. Born cross-platform, they’d be really easy to build, and bold new possiblities were just around the corner. I still believe webapps will be part of the future, but recently I’ve started to think it’s going to be a bit more muddled than that. If you’ll indulge me the explanation will be somewhat roundabout.

The mobile era in computing, more than anything, helped propel interface design patterns ahead much faster than decades of desktop operating systems did. We used to discuss whether your app should use native interface widgets or if it was okay to style them. While keeping them unstyled is often still a good idea, dwelling on it would be navelgazing, as it’s no longer the day and night indicator whether an app is good or not. In fact we’re starting to see per-app design languages that cross not only platforms, but codebases too. Most interestingly, these apps don’t suck! You see it with Google rolling out Material Design across Android and web-apps. Microsoft under Satya Nadella is rolling out their flatter-than-flat visual language across not only their own Windows platforms, but iOS and Android as well. Apple just redesigned OSX to look like iOS.

It feels like we’re at a point where traditional usability guidelines should be digested and analyzed for their intent, rather than taken at dogmatic face value. If it looks like a button, acts like a button, or both, it’s probably a button. What we’re left with is a far simpler arbiter for success: there are good designs and there are bad designs. It’s as liberatingly simple as not wearing pants.

dogma (noun)
a principle or set of principles laid down by an authority as incontrovertibly true

The dogma of interface design has been left by the wayside. Hired to take its place is a sense of good taste. Build what works for you and keep testing, iterating and responding to feedback. Remembering good design patterns will help you take shortcuts, but once in a while we have to invent something. It either works or it doesn’t, and then you can fix it.

It’s a bold new frontier, and we already have multiple tools to build amazing things. No one single technology or platform will ever “win”, because there is no winning the platform game. The operating system is increasingly taking a back seat to the success of ecosystems that live in the cloud. Platform install numbers will soon become a mostly useless metric for divining who’s #winning this made-up war of black vs. white. The ecosystem is the new platform, and because of it it’s easier than ever to switch from Android to iOS.

It’s a good time to build apps. Come up with a great idea, then pick an ecosystem. You’ll be better equipped to decide what type of code you’ll want to write: does your app only need one platform, multiple, or should it be crossplatform? It’s only going to become easier: in a war of ecosystems, the one that’s the most open and spans the most platforms will be the most successful. It’ll be in the interest of platform vendors to run as many apps as possible, whether through multiple runtimes or just simplified porting. It won’t matter if you wrote your app in HTML5, Java, or C#: on a good platform it’ll just work. Walled gardens will stick around, of course, but it’ll be a strategy that fewer and fewer companies can support.

No, dear reader, I have not forgotten about Jobs’ Thoughts on Flash. Jobs was right: apps built on Flash were bad. That’s why today is such an exciting time. People don’t care about the code behind the curtain.

If it’s good, it’s good.

A Chromecast with a Remote

The internet is a series of tubes.

Last week Android TV leaked on The Verge. The leak was conveniently timed right after the Amazon Fire TV release, and featured unusually clear screenshots that were perfectly front facing but appeared lightly filtered, almost as if to make them appear as though they were unintentionally leaked. Regardless of intent, it gave us an insight into the set-top box that Google is supposedly building.

Just a couple of months ago I bought into the Google Chromecast, a headless HDMI dongle that streams the internet to your TV. The Chromecast is as simple as can be: it requires you to use your handset or tablet to control it, so there are no “apps” per se. In fact, in order for Netflix to support the Chromecast, it has to offer its content — movies, TV shows, poster art, box art — as URLs. Because the Chromecast can read nothing else.

That’s where it gets interesting. The article in The Verge suggests an obvious question, why is Google making a set-top box that requires apps when its first successful TV device required none? Thankfully, GigaOM filled in the blanks in their article on the technology behind. If I’m reading the tea-leaves correctly, Google have indeed cracked it, and the Android TV doesn’t really require apps — not in the way we’re used to:

I’ve been told that Google’s new approach wants to do away with those differences by replacing these custom interfaces with standardized templates. Publishers wouldn’t need to come up with their own user interface, but instead would develop apps that provide data feeds to the Android TV platform.

Read it this way: you don’t have to make an app for the Android TV, your content just has to be URL accessible. In fact, if a service is already Chromecast ready, putting it on Android TV will probably require very little work. It’s quite clever; just expose the content-tube endpoint and  you have the best of the internet in a native experience, like an RSS feed for television.

Android TV is just a bigger Chromecast, with a remote-control and an interface, should you prefer that. Ted Stevens was right all along.

A Chromecast with a Remote

The internet is a series of tubes.

Last week Android TV leaked on The Verge. The leak was conveniently timed right after the Amazon Fire TV release, and featured unusually clear screenshots that were perfectly front facing but appeared lightly filtered, almost as if to make them appear as though they were unintentionally leaked. Regardless of intent, it gave us an insight into the set-top box that Google is supposedly building.

Just a couple of months ago I bought into the Google Chromecast, a headless HDMI dongle that streams the internet to your TV. The Chromecast is as simple as can be: it requires you to use your handset or tablet to control it, so there are no “apps” per se. In fact, in order for Netflix to support the Chromecast, it has to offer its content — movies, TV shows, poster art, box art — as URLs. Because the Chromecast can read nothing else.

That’s where it gets interesting. The article in The Verge suggests an obvious question, why is Google making a set-top box that requires apps when its first successful TV device required none? Thankfully, GigaOM filled in the blanks in their article on the technology behind. If I’m reading the tea-leaves correctly, Google have indeed cracked it, and the Android TV doesn’t really require apps — not in the way we’re used to:

I’ve been told that Google’s new approach wants to do away with those differences by replacing these custom interfaces with standardized templates. Publishers wouldn’t need to come up with their own user interface, but instead would develop apps that provide data feeds to the Android TV platform.

Read it this way: you don’t have to make an app for the Android TV, your content just has to be URL accessible. In fact, if a service is already Chromecast ready, putting it on Android TV will probably require very little work. It’s quite clever; just expose the content-tube endpoint and  you have the best of the internet in a native experience, like an RSS feed for television.

Android TV is just a bigger Chromecast, with a remote-control and an interface, should you prefer that. Ted Stevens was right all along.