phonezilla

Based solely on what I’ve seen and read (note!) about Android’s upcoming tablet-centric Honeycomb release, and my experience with Android on my smartphone, I think the difference between Android and iOS is quite clear.

Android is looking to bring desktop computing to smaller, newer form factors. iOS is looking to redefine computing for smaller, newer form factors.

I don’t see Android destroying any desktop paradigms, offhand. It may take some ideas from iOS and improve them (notifications look to be way better.) It is definitely taking desktop ideas and changing them. But even the fact that there’s a dashboard/home screen which has widgets that are user-configurable shows the difference: you need to devote time to customizing an Android device to make it work the way you want.

This is a trade-off which many people are fine with and, in fact, may tout as a great thing. For me, though, the value of not having to fully customize and configure a system is a large one - and, I suspect, it’s true of many people who haven’t historically been computer users.

I received a Lands’ End catalog yesterday. I normally take these catalogs from the mailbox and deposit them directly into the recycling bin, but this time I took a few minutes to look through it while cooking dinner.

And, you know, it worked on me. As I leafed through the selection of men’s clothes my mind drifted to buying more things from them; by today I was thinking that it might be time to replace a few dress shirts.

Shopping the Lands’ End site is a very different experience than leafing through one of their catalogs. Notably, shopping the Lands’ End ecatalog is yet another experience. In this case the catalog served a middle ground for me: I wasn’t in pure shopping mode (ie, had a particular goal in mind) but I also didn’t want technology in my face (ie, the ecatalog’s interface gets in my way.)

Touch interfaces bring us a lot closer to that same middle ground but, as the mostly-failed magazine apps for iPad prove, we have a ways to go.

I was planning to write a detailed review of my Android experience, but in lieu of that I’ll summarize: too many compromises, not enough satisfaction.

One thing I see both as a blessing and a curse with the iPad is that affordances are mostly gone in the interface. Sometimes I just try stuff to see what happens, and sometimes the results are good.

I use Reeder for RSS (so should you) and discovered a very handy feature: pinching and expanding works in a few ways.

• In an article, expanding will get the full article via Readability, even if the RSS feed is snippets-only. This is awesome. Pinch to go back to a snippet.
• On the main feed page, expanding and holding open a feed’s card will let you preview the first five headlines and articles inside. Very handy to get a quick peek at what’s happening. You can just expand the card without holding to view the feed.
• Opposite of above: pinching a feed reduces it back to card form.

Handy stuff, but I also have no idea how I was supposed to “just know this” in the UI.

I use Pages on my Mac (though I’m going to give Ommwriter a shot) and, for instances when print presentation matters, Pages on my iPad. A few nights ago I was writing stuff on Mac Pages and thought I’d keep all my bases covered by moving or copying them to my iPad, where I could open them with Pages.

This was surprisingly awkward. Here are the steps I took.

First, note that iTunes has an “Apps” tab and a file sync section. This section breaks out which files live on the iPad and allows you to add new ones as well as save said files on your Mac.

I tried dragging and dropping my files to this panel. No dice. Then began the comedy of errors: I chose “Add” and selected all the files via a dialog box. The files were then copied over (thus, if I changed them on my Mac, I’d need to recopy them.) I opened up Pages on my iPad and was surprised to not see my files in the carousel. “Weird,” I thought. I scrubbed all the way left and right, just in case.

I tried out the import icon below an existing document and, sure enough, found a “Copy from iTunes” button. I pressed it and was presented with a list of files from the iTunes holding tank. Surprise! Here are my files.

Relieved, I pressed one of my Pages files, got a progress bar, and… an error message! The version of Pages I was using on the Mac is slightly older and, for some reason, the iPad version couldn’t open the file. Note that the only time I got this error was after I copied the file over and chose to import it - the absolute worst time, that is. So none of my files worked and they’ll never work. Gee, thanks.

The whole concept of a holding tank for files I’ve copied over is absurd, because it’s not made perfectly clear in either iTunes or iPad’s Pages that these files are just out there in space. I’ve already dinged Pages for its poor file management, and this little oddball syncing mishap only underscores how tacked-on the whole thing feels.

So in the end, I used RTF files in Dropbox, and everything just worked. As it should.

If your site has them, forms make or break your experience. One lousy validator or error message can disturb the entire process. There are a few standards I, like you, have dealt with long enough. It’s 2011; let’s make these right.

- Requiring slashes on dates (1/2/11).
- Requiring leading zeroes ever on anything (01/02/11).
- Requiring dashes and/or parentheses in US phone number inputs ((312) 555-1212, 312-555-1212.)
- Automatically moving focus between fields in a form; this is usually used when three input fields are used as pseudo-validation for dates.
- Allowing me to exceed a limit on the number of characters you can accept; ie, not setting the maxlength property on an input field.
- The Reset button. Pretend it doesn’t exist.

Forms need to be air tight. Not modernizing your forms and allowing humane input puts an undue burden on people. Let’s not do that.

Last week I took possession of a Samsung Intercept. It is not the fastest, most glamorous Android phone on the market but it has one clear advantage: it’s available on Virgin Mobile’s prepaid service, and the monthly cost with unlimited data is $25. Prepaid has been my mobile phone service of choice for a few years now; an iPhone is likely in the future, but not for a couple of years.

As you can imagine, then, it’s been interesting working with this OS versus iOS. My wife has an iPod touch, and I’ve used enough iPhones to know what they’re like, so I wanted to get a few of my first impressions about Android out. (Note that some or all of these items may be specific to the phone instead of Android but, for my purposes, the phone and OS can’t be separated.)

First, animations and scrolling are not terribly smooth. On the iPad, even under iOS 4.2, animations between apps and panels tend to be buttery smooth. On the Intercept, they are usually herky-jerky. It’s a little thing but very noticeable and was maybe the first thing I caught.

The app paradigm is a little different. The default app launcher has a drawer which contains all of one’s installed apps, and a user can have multiple home screens with customized app placement. If you delete something off your home screen, the app isn’t really gone - it’s just back in that “all apps” bucket. I haven’t yet found a way to delete an app I haven’t installed myself. I suspect this is a stinky carrier limitation. One nice thing about the platform, though, is that I was able to totally replace the home launcher app with a nicer one. It still has an all apps drawer.

Android leans very heavily on contextual menus, accessed through a “menu” button. Many tasks are hidden away here.

The aesthetic is rather stark, mostly dark, and feels like it has taken on qualities of BlackBerry OS and Windows Phone.

The Intercept has a physical keyboard which can be used in lieu of the on-screen one in landscape mode. It feels natural to use the physical one, which naturally takes up no screen space. The portrait software keyboard is surprisingly good.

Some apps have explicit quit commands, like Pandora, and others do not. This looks to be a crapshoot.

Being able to pop in a microSDHC card for media is lovely. I’m looking to use the Intercept as my main media player - replacing my 5-year-old iPod - so once I have the new memory card, I’ll note my thoughts on that use case.

All told, Android is quite different than iOS. It has a different set of core ideas and definitely begs for more “tinkering” time. With the iPad I synced it to my Mac, grabbed some apps, and was good to go. With the Intercept, I don’t yet feel like I can just go with it; I feel that I need to spend more time making it more personal. This is a trade-off, and it’ll be interesting to see how I feel about this in six or twelve months.

I gave Google a gentle jab recently over its use of a floppy disk to denote saving a file in Google Docs. I do realize that the floppy, while no longer in use, still denotes the act of saving files for a lot of users. I began considering what the alternatives could be and it is certainly not an easy communication problem to solve.

Before we tackle that concept, though, we should first ask if most consumer software needs to provide a user-facing save facility at all.

Saving harkens back to Olde Tyme Computing where one needed to manually save a file lest a computer lock up, reboot randomly, or otherwise take one’s work with it. Since we’re getting well past that point in modern times, saving helps answer two questions: “Is your work at a good stopping point?” and “Where do you want to put this thing you’re working on?” As with many other mechanisms there are a lot of other questions and considerations which come into play (the file and folder construct, naming a file, opening and closing) but these are the two key drivers based on my experience.

The Stopping Point

Whether users are conscious of it or not, they’re creating mini-project plans in their heads when they’re creating documents. There’s a starting point, an ending point, and milestones along the way. These points might all be passed in one sitting or they might not but there’s usually some point at which a document is “done.” Saving gives users the opportunity to define their breakpoints (milestones) and endpoints. While software abstracts this project plan away, it’s possible to go even further.

Consider removing an explicit save command. What is left in its place? Likely something along the lines of a history viewer, showing all of the major and minor changes over time for a given document. Such an interface could be really geeky in a time display sort of way, highlighting “more important” and “less important” changes depending upon criteria appropriate for the program. (Add in three paragraphs to a five paragraph paper and that could be major; take out six words in a 6,000 word document and it could be minor.) Analytics and learning are sophisticated enough to help guide users into understanding what work they’ve done. Alternately, users could note major and minor changes to help the process along. All of this work would be optional; people might just want to compare last Tuesday’s work to today’s, for example.

The frequency of saving in this model would be handled by the OS and not the user. iOS encourages developers to save documents every 2 seconds. This seems reasonable.

An alternative to a timeline view, and one which may be a little less radical, is undo and redo which works all the way back to the point of document creation. This would work best for a document with a relatively small number of changes, but would fall down when that number became really large. There are also conceptual issues that would make Doc Brown nervous: if one works with a file and “undoes” work to the point of four weeks ago, and then makes changes, does the “redo” history go away? Or does it split into an alternate timeline? Meaty issues which suggest why today’s save action is usually destructive, but the ability to always have every revision of a file available is a remarkable one. The “deep undo” metaphor could be a way to implement it.

Where Does It Go?

I’m a proponent of removing the file/folder abstract in most computing environments so, to me, the question of “where” a document goes is outmoded. A document is “in” the app. There is no separation between the app and the document when it comes to work.

If a user wants to work with words, she uses the word processor. If she wants to mail a photo, she uses either the mail app or the photo app. Some tasks may overlap between apps, but they tend to be communication-driven (mailing, posting to Facebook, testing, etc.) and could be integrated into both apps.

One thing to keep in mind is that files and folders still exist, but they are essentially tools for programmers and not end users. It’s a bug that users weren’t given a feasible alternative to document storage until relatively recently. While this “app as document store” model is still emerging, it removes a deep burden.

If the concept of saving is removed, then the question of where a file “goes” is also removed. It lives in the app.

How We’ll Get There

These are large-scale changes, to be sure. The concept of saving files is ingrained in our computing culture, built on a history of unreliable OSes and media.

Apple is trying to just up and change it. Apps for the new Mac App Store need to save files automatically and silently - much like iOS. It makes sense for iOS, a relatively new OS, to run with this convention. It’s not out of the question for Mac OS, either, nor is it absurd to think that Chrome OS could pick it up. 

What about Windows? Given its seasoned users I think Microsoft should take a more gradual, less radical approach. The “deep undo” concept is an option, as is beginning to deemphasize the act of saving: keep it around but begin to give it less and less prominence in the UI, supplanted by some sort of history viewer.

Computing devices are starting to become very diverse but many of the latest and greatest devices do away with old conventions. If we truly want user experience to move forward, we should be giving users a hand every step of the way. The concept of saving files as it stands today is outmoded and awkward, so let’s make it reliable, easier, and better.