More Thoughts On Feedback

It occurs to me, as I think more about the problem of interface feedback, and as I ponder the things in computing that drive me bonkers, that the problem of feedback — when to let a user know that something has happened or that something is happening — seems to be one that's getting worse. I complained about it a lot in my criticisms of The Mac App Store, but it bothers me throughout a whole host of applications.

The browser, for instance: I often find myself clicking a link to a slow website — or maybe there's some other network hiccup — and nothing happens. Or at least that's how it seems. There actually is a subtle indication that I've successfully clicked, and it comes in the form of a pinwheel or a progress dial in the loading tab — what we used to call the Throbber back in the Netscape days — that tells me that, yes, I clicked and now the page is loading. But these subtle indicators are often lost on new users, or less tech-savvy ones. And, to be quite honest, they're often lost on me as well.

Links are small, and with the inaccuracies that tend to accompany touchpad use, I miss them a lot. This is especially true on pages like Facebook which often load new content just before you click said link, causing your link to shift position, thus causing you to miss it through no fault of your own and in a way that you might be completely unaware of. So it's important to know simply that you clicked. That you nailed it.

Clicking in one spot and then having to look in a completely different spot to see if I successfully clicked is not only inefficient, it's really annoying. It totally breaks my flow and it also doesn't make much sense except within the historical context of the Netscape-style Throbber. Why not make the progress indicator closer to the link you just clicked? Or cover the page with some sort of translucent graphic? Or use some sort of Heads Up Display?

The Finder is guilty too. The throbber for searches performed in a Finder window is a small radial line throbber in the status bar in the lower right corner of the window. By default, in Lion, the status bar is hidden, thus the throbber, too, is hidden by default. But even when visible, it's nowhere near the search bubble, nor is it anywhere near where the search results begin to appear. Unless you know that the throbber is there — and I certainly missed it for a long time — you'll likely be oblivious to its existence.

But, you say, search results appear so instantaneously, there's no need for a throbber. Well, sure, except when they don't. Say you're searching a network volume, for instance. This type of search is much slower since it doesn't rely on the local Spotlight database to perform the search, so results can take some time to appear. Also, without a throbber, how do you know when Spotlight has finished searching, particularly on a large volume with lots of results? Feedback, my friends. Feedback.

This should be the rule — and maybe it already is somewhere, but if it isn't it should be. If I click on something I should get immediate feedback that tells me simply that I successfully clicked, that I hit my target, and it should be obvioulsy apparent. Details beyond this, like what's happening now that I've interacted with my computer, should also be evident. But it seems like lately we're really falling down on the, "Hey, you clicked something," front. And it's been bugging me. A lot. Because in computerland, clicking on something and receiving no feedback whatsoever has always meant one thing and one thing only: it's broken.

Browser developers, OS programmers, you want to rethink an interface? You want to make a better mousetrap? Start there. Start with feedback. It's quite basic, but feedback is so very important to the computing experience. And while I wouldn't say it's completely broken, it, like everything in life, can always get better.

Long live the Throbber!

UPDATE: One reader has decided to begin recording every instance of radial throbbers he can find. Check 'em out at Samuel Henry's Space!

Automation and Feedback

One of my overarching problems with Lion, I'm slowly realizing, is that it's trying to do too much for me. Don't get me wrong, I think this is, in many ways, a good direction. I've long wondered why I had to save every document revision by hand. Isn't this a job a computer would be way better at than a human?

Indeed.

But the problem with the computer doing too much for me is really an implementation problem, and in the end it boils down to one main issue: communication. I don't mind the computer doing things for me, but I need to know about it.

Case in point: automatic spelling correction. Apple has rolled iOS's auto-spell correct into Lion, and now I find myself making all the same sorts of word choice errors in my documents that I make in my text messages. Here's the thing, though. In the past, when I'd make a spelling error, TextEdit would put a big red squiggle under my misspelled word. Later, when revising something, I'd easily spot the mistake and correct it by hand.



Now, with automatic spell-correct, TextEdit sees my misspelled word and corrects it, so there is no red squiggle. And with no red squiggle there's nothing to tell me, upon revision, that there might be mistakes in my document — mistakes which take the form of incorrect words rather than misspellings, but mistakes nonetheless — mistakes made by the computer.

While I generally like auto spell-correct, I think it would be much improved with some sort of notification system. Perhaps a subtle highlight, or a blue squiggle, under every word that was corrected by the system. That way, when you go to revise your document, you can see where the computer has intervened and perhaps made an unfortunate word choice.

Extend that idea to Versions and I think I'd have a lot less to complain about with the versioning system as well.

Overall, I think there are some good ideas here in Lion. But there's definitely room for improvement.

Securely Erasing a Mac SSD

I've recently made the switch to an SSD for my boot drive. And, yes, it is good. Everything feels all buttery smooth now; I don't feel like I'm waiting for my system to catch up to me as much. It was a bit of a hassle, but totally worth it. But that's not what I'm here to talk about.

The Problem

If you ever want to, say, sell your now SSD-equipped computer, you're probably going to want to erase its contents as securely as possible. Back in the HD days, this was very well-understood and relatively easy to do. You simply overwrote every bit of data on your Hard Drive numerous times with zeroes or random data or what have you. There are command-line tools that allow you to do this, as well as Disk Utility's Secure Erase Options, which allow very secure and thorough erasure of a drive. But because of the way that SSDs work, all this goes out the window.

I'm not a Hard Drive or SSD expert, but, in a nutshell, in order to maintain performance and increase longevity, SSDs add another level of abstraction between the device and the filesystem that makes it impossible for the OS to accurately know the location of a given file on the actual device. This means that it's virtually impossible to securely erase individual files. So the question becomes: How do I securely erase the entire drive?

We Want... Information (-ation, -ation)

The tools and procedures for securely erasing SSDs are not self-evident. I poured over a pretty hefty amount of literature before arriving at a method that I think will work fairly effectively. Since there's no way to accurately erase individual files, this method erases the entire SSD. And since the best way to do this, while still balancing usability and effectiveness, is to use encryption, we'll be enabling FileVault 2 in Lion, as well as, of all things, Find My Mac in iCloud. I'll go over all of this in a bit, but let me first talk a bit about my thinking.

My Thinking

The most secure way to delete an SSD is to find a way to scrub the drive, to go through every cell on the SSD and overwrite the data, similar to how you would securely delete a typical hard drive, but at the hardware level. Out of the box the Mac has no way to do this. There are a variety of Linux and Windows utilities — some of which come directly from the drive vendors — that allow you to do this, but they require a huge number of hoops to jump through, not the least of which is creating a Linux LiveCD or Windows machine to boot from, as well as a significant time investment. Using this method, while perhaps a more secure deletion of the data, will be time consuming, difficult and error-prone.

As I mentioned, there's a ton of literature on the topic of securely erasing SSDs, but the vast majority of it is theoretical. There are very few articles that actually tell you, practically, how to go about securely erasing your SSD. What got me thinking in the right direction was an article from Ars Technica that very broadly discussed the various difficulties with and methods for secure SSD erasure. In it, they talk about drive scrubbing approaches, but then they also mention using an encryption-based approach:

"The most popular option for protecting data, absent of robust secure erasing tools that scrub right down into the over-provisioned cracks, is to encrypt the SSD's contents. This way, if someone's coming after your data, the only thing you need to make sure is off the drive is the security key (128- or 256-bit AES is recommended) and your bits will be safe, unless whoever wants your data is up to cracking that code."

This caught my attention, because it sounds very much to me like the secure erase procedure that newer iPhones use. If you've ever securely erased an iPhone 3GS or later, you may have noticed that it goes extremely fast. Older phones take a long time because they're actually scrubbing the SSD clean of data, but newer ones are really fast because all they're actually doing is deleting the encryption key, making the data virtually impossible to access.

Finding a similar procedure for an SSD-equipped Mac was no easy feat, but I think I've dug one up that may work for most typical users who just want to pass on their SSD-equipped Macs without worrying about someone accessing their private data. The thing that's tricky about doing this is that Apple has provided no similar utility for erasing SSDs as they have for the iPhone. On an iPhone you simply go to your Settings and choose:

General->Reset->Erase All Content and Settings.

There is no such utility on a Mac.

Or is there?

Enter: FileVault 2

Mac OS X10.7, Lion, has a new feature called full disk encryption, now popularly known as FileVault 2. What FileVault 2 does is take all the data on your boot drive — which in my case is my SSD — and encrypts it. The encryption key is stored on the disk and is only accessible with your home account password (or any other user's password that you allow). In and of itself, in fact, assuming you have a reasonably secure password, simply enabling FileVault 2 on your boot drive provides a pretty decent degree of security: No one can access the contents of your disk without your password.

Encryption key deletion, a la the iPhone, provides the final layer of security, but how do you go about doing such a thing? The Apple literature on FileVault 2 makes reference to something called "Instant Wipe:"

"With FileVault 2, instant wipe removes the encryption key from your Mac instantaneously, making the data completely inaccessible."

Enter: iCloud & Find My Mac

I have yet to find a way to access this "Instant Wipe" from my Mac, nor is there any reference to it in the Help files. But with the addition of the Find My Mac feature, now freely available via iCloud, a Mac can securely erase a drive in a fashion quite similar to that of the iPhone. Find My Mac allows Mac users to remotely locate and lock, send messages and alert sounds to, and — most important for our purposes — wipe a lost Mac. Of course, this functionality works perfectly well with Macs that aren't lost as well.

Sending the "Wipe" command to your Mac from Find My Mac (either via a browser logged in to iCloud or from Find My iPhone on your iPhone) will do the same thing to your Mac that Secure Erase does on your iPhone. It will erase the encryption key that protects the data on your SSD.

"The Remote Wipe command is, of course, a last resort, as it instantly destroys the boot drive's contents by erasing the encrypted volume's key, rendering the drive's contents unusable."

This means that, once the encryption key is deleted, even you will no longer be able to access your data with your password. Once this happens, the only way to access the data is to decrypt it, and without the key, this is a monumental task far beyond the capabilities of most users. The XTS-AES 128 bit encryption that Lion uses is extremely difficult and time consuming to crack. In fact, though there are more secure options out there, I believe this one has yet to be cracked at this point.

Also, once the encryption key is wiped, the wipe command apparently goes through and deletes all the data as well:

"Instant wipe removes the encryption key from your Mac — making the data completely inaccessible — then proceeds with a thorough wipe of all data from the disk."

It's unclear exactly how this wipe is performed. Does it happen at the hardware level clearing data from each and every cell of the SSD? Are the files overwritten multiple times with random data or are they just marked offline? It's hard to tell from the scant online literature I've seen; even the developer docs seem to be out of date. But whatever the case, this is pretty durned good security for the average joe.

So, how to get all this working? There are only two things you need to set up: FileVault 2 and iCloud with Find My Mac

This article is already long enough, so I won't go into FileVault 2 or iCloud setup here. They're easy to do and there's already plenty of information about the procedures. Here are some great links to get you started:

Set Up Filevault 2

Set Up iCloud's Find My Mac

Suffice to say, once these services are configured, erasing your SSD, when the time comes, should be as simple as logging in to iCloud, locating the Mac in question using Find My Mac, and issuing the Wipe command. After a very short amount of time, the encryption key will be deleted, and some time later (how long depends on a number of variables, some of which we don't actually know), your disk will, in theory, be wiped clean of data.

One caveat: I have yet to actually try the Wipe command. Oh, believe me, I intend to. But we're talking about a day out of my life, and that's a day I just don't have to spare. And you know what they say about good intentions. Yeah.

If I do manage to get around to this, I'll certainly post my findings here. I encourage others to do likewise in the comments section of this article.

MORE:

http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/13

http://en.wikipedia.org/wiki/Whole_Disk_Encryption

iBooks Author

I've been poking around a bit with iBooks Author. It's something I find very interesting. See, I've actually been working on a book myself, though maybe not the sort of book you might imagine. It's not a tech book at all. It's actually a comic.

While I'm nowhere near ready to publish, I'm nevertheless understandably interested in digital publishing options. The ePub format is how I've envisioned digitally publishing my book thus far, but iBooks Author offers a whole new wrinkle.

The iBooks Author Format

Like a lot of folks, I was a bit irked when I heard that iBooks Author creates files in a proprietary format only accessible to iOS. It would certainly have been possible for Apple to make iBooks Author create standard ePub formatted content. And that would be nice, but the more I look at the tools, the more I realize that using the ePub format would completely miss the point of this platform. What Apple is trying to do here is change the standard. In the same way they want to revolutionize the world of textbooks, Apple wants to change the way books are made and read. By making them interactive. This is clearly the goal for iBooks Author. Sure, you can make non-interactive books with it, but that misses the point entirely. iBooks Author makes something no other tool can make. And that something is made to run on an iPad.

iBooks Author Beefs

You may note that I said iPad in that last sentence. That was no mistake. From what I can tell, iBooks Author content is not just iOS only, it's iPad only. The Textbook category doesn't even show up in iBooks on the iPhone. Nor can you export from iBooks Author to iPhone. In fact, it's so iPad-centric that even vertical and horizontal orientation are authored for different appearances and behaviors. That's right, a horizontally held iBooks Author product will appear and behave differently than a vertically help one. The iPhone doesn't do this. This is pure iPad, folks.

There are two reasons I put this in the "Beefs" category. The first is that, well, I don't have an iPad, so I have no real way to play with the full iBooks Authoring process. I hope to have this issue corrected eventually, when I finally do end up getting an iPad. I can tell you, iBooks Author is one more reason to do so, and I can see getting one soon.

The other reason is that, somewhat oddly, portrait mode seems to be geared toward reading text. In this mode, text dominates the page and images and other media are added to the sidebar. Tap one of these sidebar items and you'll see the full-screen version, but this layout does not work well for making comics, which are single images on a vertical page. This may make iBooks Author less than ideal for making traditional comics digitally. (And actually, I should point out, making a traditional e-book from a comic is probably the easiest kind of book you can make.) To further illustrate iBooks Author's landscape-centricity, there's even a setting to disallow vertical orientation. But not the other way around.

But this just underscores the point I'm trying to make about iBooks Author. iBooks Author is not about making traditional books. It's about making something new, something specific to the iPad, a new reading experience entirely. One that's rich and interactive. And that's got me thinking about my book in new ways.

iBooks Author Coolness

What ultimately is cool about iBooks Author is this: If you think about it, it's a lot more than just a textbook creation tool, or even just a book creation tool; it's essentially a media wrapper for building simple interactives for iPad. The confusion comes from the name. iBooks Author creates books, right? But again I say, Apple wants us to re-envision the book. This is a book in name only. And this new book lies somewhere between book and application.

What these "books" remind me of more than anything else are the interactive kiosks we have here at the museum. These interactive screens aim to educate and entertain simultaneously by creating an engaging personal experience. The visitor chooses and interacts with the content. They have a certain level of control and agency not afforded by static displays, nor by straight video. And I believe this approach, when done well, can encourage learning.

Using iBooks Author

iBooks Author is very much in the iWork vein. In fact, using it is very, very similar to using Keynote. Keynote projects — as well as Word docs and Mac OS X Dashboard Widgets, for that matter — can even be embedded right into iBooks Author projects. Essentially, as in Keynote, you have an outline on the left and a viewer in the center where you add and modify text and other media. Perhaps the biggest difference is that you'll be authoring in iBooks Author for both vertical and horizontal views. But otherwise, it's very similar.

Conclusion

I have high hopes for iBooks Author. I actually see it as a way to make interactive content that goes far beyond our typical notions of what books are. I suspect  a lot of people will find a lot to like with this tool and the potentially magical things you can create with it with ease and simplicity.