Blog DirectoryKartik's Log

Listing Details

Recent Posts:

ID:	1384
Title:	Kartik's Log
URL:	http://kartik-log.blogspot.com/
Category:	Computers: Programming
Description:	Thoughts on programming, languages, software and computing.

Examining the integrated model - Thu, 22 Dec 2011 04:51:00 +0000

I've heard for almost a decade that the fact that Mac OS X runs only on Apple hardware makes for a better user experience. I hadn't really understood why or stopped to think about it, so I did that now, and here are some ways it helps.

Lion's fullscreen mode is amazing. The three-finger swipe makes it easier to switch between fullscreen apps (or spaces, for that matter) than to switch between windows. This is a tremendous achievement, since the traditional full-screen mode makes it harder to switch between apps, and so full-screen is not used much, except for movies and presentations. Besides, Lion's full-screen mode makes the Mac more of a distraction-free device like the iPad, making it pleasanter and more relaxing to use. It also makes better use of screen space, which I never have enough of on my 15-inch Macbook, let alone on 13- or 11-inch Macbooks. In fact, one could say that Lion's full-screen mode lets us have these small laptops in the first place, without severely trading off comfort or productivity. Finally, smaller laptops are lighter, more portable and cheaper. All this is made possible because of Lion's full-screen mode, which is practical to use only because of the three-finger swipe.

This requires a trackpad that supports three-point touch, is sensitive enough, and big enough that you can comfortably swipe with three fingers. There are other multitouch gestures in Lion; three-finger swipe is just an example. The point is that it doesn't make sense to build multitouch gestures into the OS without hardware that makes it convenient enough to be useful or vice-versa. Otherwise, you just get a meaningless item on a checklist. Windows PCs suffer from this perennial chicken-and-egg problem.

Apple can add dedicated hardware buttons for things like Mission Control. Again, how easy it is to use something often determines whether it makes sense in the first place.

Macs don't need you to install drivers for things like the webcam, extra keys on the keyboard, the infrared remote control, etc. Drivers on Windows are not well integrated into the OS and feel like a kludge, they don't show up in Control Panel, they need to be separately installed and updated, they make the system slower, clutter up the system tray (I don't need an icon for my webcam any more than I need one for my hard disc), come with bundled crapware apps, and generally don't work anywhere as well as on the Mac. I remember when I switched to the Mac a few years ago that everything worked without all this detritus. It was a "less is more" moment for me.

Apple can add hardware capabilities like WiFi Direct to enable features like AirDrop. In retrospect, isn't it backward not to make use of physical proximity to send files more easily?

Apple has eliminated support for obsolete hardware to simplify and improve things for users. For example, Apple has been using EFI for years, while most PC hardware is stuck with BIOS. EFI boots faster and from hard discs bigger than 2.2TB. Similarly, Lion requires a 64-bit CPU. This is easy since Apple hasn't shipped a Mac with a 32-bit CPU in years. Whereas Windows 8 still has to support 32-bit CPUs. When I read that to boot from a 3TB hard disc, you need 64-bit Windows (which of course requires a 64-bit CPU) on a system with EFI rather than BIOS, it makes me angry. Why does this stuff have to be so complex? Why should someone configuring a machine with a bigger hard disc for their movies have to get their hands dirty with all this arcane stuff? Why can't the damn thing just work? Computers are broken in many ways, and getting rid of legacy stuff, as with this example, simplifies things for users. This is much easier when you control both the hardware and the the software.

Mac USB ports provide extra power for iPhones to charge quickly (1100mA compared to the 500mA maximum under the USB 2 spec) [1]. Similarly, Macs can wake up when accessed via WiFi, not just Ethernet.

Internet recovery is built in to the firmware on recent Macs, so if you have a hard disc that's somehow been wiped clean, you can boot off Apple's servers and run the installer, rather than having to boot from a DVD (you may not have a DVD or a DVD drive). A Mac can no longer get into a state it can't recover from, and this is possible only because Apple controls the firmware.

OS X doesn't need to handle an endless variety of hardware, including broken ASUS stuff.

The bottom line is that if you're in the business of making the best user experience, the integrated model is the way to go.

Footnotes:
[1] For that matter, I wish Apple supplies 100W power via the Thunderbolt bolt on the Apple Thunderbolt Display, so that you can plug your Macbook or Mac Mini into your Thunderbolt Display with a single cable for charging, video and data. When your data cable supplies all the power you need, you don't need another cable.

Similarly, iPads should use a Thunderbolt port so that you can plug it in to a Thunderbolt Display and have it charge while using the external monitor (and maybe even a keyboard and mouse), or plug it into a Mac and have it charge (iPads need 10W, and Apple's USB ports supply only 5.5). It doesn't make sense for Apple to have two different connectors that both support data, power and video.

Simplifying the Mac Branding - Mon, 14 Nov 2011 16:30:00 +0000

Since the branding for Apple's current Mac line seems to have evolved organically, starting with the iMac in 1998, I wanted to see if we can overhaul and simplify it, so that it stays fresh and relevant for the future, rather than being an artifact of the past. Of course, we want to retain its distinctiveness, and minimize unnecessary change.

The iPhone is an excellent brand name. It's distinctive, while fitting in to the overall Apple brand (the "i") and being minimalist, by just adding one letter. It stands for Apple's quality and esthetic, products that are simple and beautiful, without a bunch of half thought-out featuresor tacked-on ornamentation.

To begin with, let's use Mac as the backbone of the brand family. It's distinctive, and so doesn't need an "i". Come to think of, isn't it weird that Apple sells some iMacs and some plain Macs? I mean, wouldn't it be odd if Apple sold an iPhone and a plain Phone?

Since more people buy Mac laptops than desktops, let's drop the "book" from the MacBook and make that the default. Let the desktops have a qualifier, instead.

So, here are the new names, on the right, with the old ones on the left:

Macbook Air->Mac Air

Macbook Pro->Mac Pro

Mac Mini->Mac Desktop Mini

iMac->Mac Desktop

Mac Pro->Mac Tower

Notice how the laptops have clean, simple names. I cringed when I first heard of "MacBook Pro". Why did Apple throw away such a sleek and modern Powerbook name for this clumsy one? Well, this rebranding fixes that.

I also like that the Mac Mini and the iMac have similar names in the new scheme, reflecting their similar nature — desktops rather than laptops or workstations. Ithinkthe Mac Mini should have all iMac features and vice-versa, except for the built-in monitor.

I think this cleaner, modern branding will stand Apple and the Mac community in good stead for the next several years, and reflect the attention to detail that makes the platform what it is.

Is the Android Back Button a Good Idea? - Thu, 10 Nov 2011 10:35:00 +0000

For some reason, the Android back button is topical again.Christopher Du RietzandJohn Gruberboth say that it's a bad idea. I'vethought so, too, an year and a half back, but I wanted to see if anything changed since then, or if my thinking evolved. So, let's look at arguments for and against the back button.

Arguments For the Back Button:

Consistency: No matter what screen you're on, there's almost always a previous screen to go back to, so it makes sense to have a standard button for it, for the same reason the browser has a back button, or iOS devices have a home button. Don't leave it to apps, because they could handle it differently.

In addition to consistent in-app navigation for all apps, you also want to use the same system to navigate out of an app as you use to return to the previous screen within the app. On iOS, you navigate within an app by using the on-screen back button, but when you reach the top level of the app, you have to use the physical home button to navigate out. This feels like apps have rigid boundaries rather than things flowing together smoothly. Android back button navigation feels more natural.

In addition to navigation within an app and navigation out of an app to the home screen, you also want consistent navigationacrossapps. This is important since Android apps blend together smoothly by invoking each other. In fact, apps on Android are composed ofactivities, one for each screen, which can be invoked from other apps. For example, the compose screen of an email app is a different activity from the inbox. Activities from different apps intermingle smoothly into an activity stack, to the extent that you navigate between apps without noticing it, and the back button is critical for this. When you click on a link in an email and decide to tweet it, you have an activity stack consisting of Email -> Browser -> Twitter. Pressing back from Twitter returns to the browser, and pressing back again, to email. This kind of seamless navigation requires a back button independent of a particular app.

This kind of smooth navigation between apps is much better than on iOS, where each app is a world unto itself, and there's a lot of friction in moving between apps. So iOS apps have to have in-app browsers for accessing links, with different functionality and interfaces and you sometimes need to tap the Open In Safari button, whereas Android apps just launch the browser, which works better.

So, to summarize, back button navigation is consistent for:

in-app navigation, no matter which app you're using.
navigation out of an app to the home screen.
navigation across apps in an activity stack.

Tactile feedback:Well-implemented hardware buttons, like on the iPhone, are easier to use than on-screen buttons. Unfortunately, many Android phones squander this advantage by using capacitive buttons (like on the Nexus S) or by using OS-controlled on-screen buttons (like on Ice Cream Sandwich/Galaxy Nexus).

Arguments Against the Back Button:

It's not labeled:On-screen buttons can be labeled to tell the user where he's going to go if he clicks the button. It should be obvious why that's better.

Intra vs inter app navigation:But there's a deeper problem — it could take you to different places depending on where you navigated from, which could even be another app. John puts itwell:

Here’s one thing I don’t like about the Android Back button that I’ve never seen a counterargument for: it presumes that you, the user, remember the activity stack. If you turn your phone on and you’re looking at a web page in the browser, if you don’t remember what you were doing immediately before opening the web page you’re looking at, you have no idea where you’re going to go if you hit the Back button. Could be another app, could be another web page, could be the home screen. And if hitting the Back button takes you somewhere you didn’t want to go, there’s no Forward button to reverse it. It’s like leaving a breadcrumb trail in the dark — you have to remember where the breadcrumbs are because you can’t see them. Drove me nuts.

By contrast, iOS back buttons always navigate to another screen in the same app, and so are less confusing. Yes, that means that apps have rigid boundaries and some friction switching between them, but it also means that the back button is less confusing, because it never takes you to another app or to the home screen.

Back or Up?Forget for now that the back button can take you to another app. Assume it takes you elsewhere within the current app. But where? Most people would say that it takes you back to the previous screen within the app, the one from where you came. But that's not always true. Here's an example: from the home screen, open Evernote. It starts by showing you the last opened note. Press back. Where do you expect to go? The home screen, right? But it actually takes you to your list of notes — a screen that you've never seen before and isn't therefore in the activity stack.

And no, Evernote's not doing anything wrong. They could "fix" it by always opening the list of notes and forcing you to navigate to the note, so that the back button takes you back to the previous screen, but that would make it less usable.

The real problem is with the back button, which sometimes behaves like the browser's back button by taking you to the previous screen in the activity stack, and sometimes like iOS's back button by taking you one level up in the app irrespective of history. It should just make up its mind and do one thing consistently.

Doesn't work well with long press app switching:We've seen how the back button can take you back in the activity stack or to a brand new screen. But it gets worse than that. It can take you toanotheractivity stack. Yes, Android has multiple activity stacks. If you were to navigate from the home screen to Evernote's list of notes, and then to a specific note, then press the home button and go to Google Maps, you have two activity stacks:
Home -> Evernote list of notes -> Evernote note
Home -> Google Maps.

Now, while in Maps, you can long press the home button to bring up the list of apps, and tap Evernote, and it shows you the note you were viewing. Now what do you expect the back button to do? One might expect it to take you back in the current activity stack (Evernote's list of notes) or to the screen you came from (Maps). This is confusing. But it's even worse — it doesboth. It first takes you back in the same activity stack, to the list of notes, but when you press back again, it takes you to the previous activity stack, to Maps.

[Actually Evernote has one more level of hierarchy, but I'm eliminated that for simplicity — it doesn't change anything here.]

It makes you go in circles:Christopher explains:

If I get a mention on Twitter and open up the Android Twitter app to check it out, I’m (naturally) sent directly to the tweet mentioning me. Ok, so I want to get back to the main timeline, what do I press? The answer is: you can’t. Pressing the back-button, which is the only real candidate for this action, will take you wherever you where before seeing this screen, which in this case was the home screen, exiting the app. Hmm, so how do I get to the main timeline? I have to open Twitter again, showing the same tweet I saw before and now press the back button, and it will take me to the main timeline.

Notice that the user's going around in circles: A -> home screen -> A -> B. I've had the same experience with other apps. Obviously, it's stupid and irritating to go around in circles. Why on earth can't I go from A to B without going elsewhere, returning to A and then going to B?

Doesn't work well with modal screens: If the user's writing a review in Google Maps and presses the back button, what does it do? The user has no clue, because it's not labeled, and doesn't even make sense in a modal screen, by definition — you want explicit Post Review and Discard buttons. But you can't remove the global back button; it's always there, whether it makes sense or not.

Learning curve:Android back buttons have a learning curve because you have to remember that some controls are on-screen and some are off-screen.

So, to summarize the problems with the Android back button:

Users don't remember the activity stack.
The back button can take you to another screen in the same app or to another app.
The back button takes you to the previous screen in the app, except when it takes you to a screen you never visited.
It can take you to another activity in the current activity stack, or to another activity stack, or both.
It makes you go around in circles.
It doesn't work well with modal screens.

This is way too much complexity. I couldn't understand or predict the behavior of the app button (despite being a programmer who builds mobile apps) and resigned myself to it behaving arbitrarily, taking me where I didn't want to go, and having to find my way back to where I did want to go. iOS's back button works like a charm, in comparison. The price of rigid boundaries between apps and friction in switching between apps is small in comparison to this massive confusion.