iOS search field should come up with all text content selected

In Codebook for iOS, when I tap search, the search text field comes up with the last search text, and teh cursor positioned at its end. When I tap the search field, it would however seem unlikely to me in most cases, that I would wish to search for the exact same text again. Instead, I have to manually delete the text field’s contents in order to search for a new term.

I would thus suggest, to have the search text field always come up with the previous text content, but with the entire content selected.

If I want to search for something else, I can simply start typing away, effectively replacing the current search field contents.

If I want to modify my previous search, I can still do that fairly easil, by tap-and-hold on the search field to position the cursor where I want to make the modification.

IMO, having the search field always come up with all text content selected would hence make for a (hopefully) relatively simple change, yet providing a big gain in ease of use.

Looking forward to your thoughts.

Hi @c_alpha,

Thanks for the thoughtful post, we really appreciate it. Looking into the issue lead us to an interesting discussion of how the different platforms handle it existing search text when the user’s focus returns to the Search field, the system standard behaviors, and the trade-offs involved.

In Codebook for macOS the Search field is a component of the AppKit development library. There we can see the behavior you’re advocating for at its best. The user can right-arrow (or mouse click to the right) to dismiss the selection and refine the search, or simply start entering a new search term on the keyboard to eliminate the selection.

On iOS, where the interface (including the keyboard) is all based on touching the screen with your fingers, and real estate is limited, the utility of doing the above bumps up against other concerns, like returning from a search result that wasn’t quite what one wanted to refine one’s search. In building the Search interface for UIKit (the library that provides the UI on iOS), Apple made the intentional decision to roll with the cancel button instead, that’s the x in a circle you see in the search field when there’s already search text present. They felt it’s a better experience to offer a quick dismissal button of existing text than the alternative, as you pointed out:

If I want to modify my previous search, I can still do that fairly easil, by tap-and-hold on the search field to position the cursor where I want to make the modification.

We agree with the Apple approach, ostensibly, that this is less than ideal and would occur a lot more often than I think people realize. In addition, it’s quite a standard behavior that users have come to expect on iOS, we’d be changing a core experience in a big way.

So, to sum up, we’ve decided to stick with the current behavior on iOS, but we really appreciate you taking the time to lay out why you’d think that would be a better approach.

Quick question: do you use Codebook on iPad as well as iPhone? If you do, do you use it with an external hardware keyboard (e.g. the smart touch cover)?

Hello William,

Many thanks for your kind consideration of my suggestion, and your insightful explanations. I appreciate your internal discussions on the topic!

I can fully understand your approach to go with whatever is the default behaviour of the platform’s native toolkit. At the end of the day, it will be the route of least surprise for the user.

To answer your question:

[…]

Quick question: do you use Codebook on iPad as well as iPhone? If you do, do you use it with an external hardware keyboard (e.g. the smart touch cover)?
[…]

I’m using it on iPhone and Mac only.

Cheers, and many thanks for making and keeping Codebook the great software it is,

–alexander

No problem at all, we genuinely enjoy getting into these kinds of details, that’s the nature of the work and we appreciate the opportunity to discuss it. And thanks so much for the kind words! More good things are afoot.