You're viewing all posts tagged with Android

Text Selection in Android and iOS

Release Candidate One:

Engadget (via Daring Fireball):

In the browser, you long press on text to bring up your anchors, then drag and tap the center of your selection — boom, copied text. In text editing fields, however, in order to select a word you must long press on the word, wait for a contextual menu to pop up, and then select “select word” — a completely counterintuitive process. In the message app you can long press to select only the entire message.

…this segment of the quote, as cherry-picked by me from John’s larger cherry-picking, applies just as much to iOS as Android.

On iOS, text selection is largely up to the app developer. There’s a lot of text you simply can’t select in apps; try selecting a song name in the iPod app, for example… no dice. Sometimes long-holding an element of the UI lets you copy the entire text of the held element, such as in Messages and Calculator, with no fine-selection mechanism. In Safari and other “web views” you long-hold and it selects the nearest word (or contents of the nearest DOM node, it depends on your zoom level) and then you can fine-tune your selection by dragging handles before hitting the Copy button. In text fields, long-hold doesn’t give you any selection, but gives you a menu to select the nearest word, or select all text, then you can copy. Still on text fields, if you double-tap-and-drag in one motion you get a selection over the dragged area, and you can then hit Copy.

The problem doesn’t lie in how many different ways there are to copy things — whether from an editable field, from a read-only block of text, etc — but in how smartly it’s implemented. I don’t hear Topolsky or Gruber complaining about the multiple use cases that we encounter when selecting/copying/pasting. I hear them saying that the implementations of those use cases in Android aren’t very user-friendly. iOS select/copy/paste has a number of different implementations across the OS, but almost all of them are smartly implemented and reasonably consistent.

As an example, in the URL field in Mobile Safari, there is a handy shortcut: if you double-tap in the middle of a URL, the selection automatically anchors itself at the very end, and selects everything backward to where your finger is. Is this inconsistent with the rest of the system? Yes. But it’s also a very well-informed design decision, and is very likely to be a welcome implementation almost every time you encounter it.

Maps.app and Google’s “My Maps”

I have to say, it is a continual breath of fresh air whenever I go into YouTube.app these days. My favorites are pulled right from my YouTube account, my subscriptions are readily available, my posted videos are there. It was painful, for so long, to go into YouTube.app, only to be greeted with a glorified search engine. Having true integration with the web service is just where it’s at.

So now, with the advent of the Google/Verizon Droid, it’s going to slowly become apparent that other web services need some lovin’ on iPhone. The first example that comes to mind is Maps.app.

For roughly the entire time iPhone has been on the market, I can recall being frustrated that users are unable to create multi-stop directions. Thankfully, it’s possible to create multi-stop directions on the desktop, and email them to iPhone. The link will open up in Maps.app, and all the stops will be plotted. But you can’t change the route, since iPhone only does A -> B directions.

But, getting back to the point, Google Maps is your Google Maps. You’ve got an account that you can personalize, it keeps a history of your searches, and there’s the My Maps feature which allows you to save custom maps for later use. The Droid reportedly handles this with aplomb (as one would expect), and your saved maps are automatically available in Android. This is what these services are meant for, and it’s silly to under-utilize them.

Now, this is where Apple has often infuriated me in the past. Because when I really stop to think about it, I don’t know that — were I in their shoes — I would do anything differently. Maps.app was quite nice in the beginning, but it quickly felt a bit simplistic. Knowing now that Apple was very invested in getting third-party developers into the AppStore, one thing has become increasingly clear: sure, Apple needed to ship solid, reliable apps on the phone, but it was debatably better for them to leave people wanting. And once you’ve given your third-party developers a chance to shine, you’re somewhat backed into a corner — if Apple make their stuff far better than the products on the AppStore, many developers are going to get all butt-hurt about it.

The bottom line, though, is that you can’t delete Maps.app from your iPhone. You’re not given the choice. So, even if you were to find a much better mapping app on AppStore, you’re doomed to have two icons. By the same token, since Maps.app is destined to be a crutch, that gives app developers ample reason not to excel. You don’t have any incentive to develop a complete/excellent replacement for Maps.app, because you can’t ever truly replace it.