There have been a couple of situations where I’ve had several small data fields along side one large body of data. The iPhone’s mail view/compose UI fits this model fairly well, and it’s something users are used to. The problem is that it can be difficult to emulate.
Taking a look at a MFMailComposeViewController’s view hierarchy can demonstrate why. One might think it’s a simple UITableView with a UITextView (or something similar) as its footer view, or as the last table cell. In fact, the hierarchy looks like this:
MailComposeView
UIView
UIScrollView
UIView
ComposeRecipientView
…
MFComposeSubjectView
UITextContentView
I’ve left out a couple of views here, it illustrates the structure. This is different from the expectation that a table is being used. Having established that Apple is not using a UITableView for this structure, let’s try to do it anyway.
The structure I’d like to use is this (I’ve included a project downloadable below):
I’m unhappy with the standard input paradigm for tabular data on the iPhone.
The most common pattern is a UITableView inside a UINavigationController. The user selects a row and a new UIViewController that allows the user to edit the value is pushed onto the UINavigationController. When the user is done, that UIViewController is popped and the user returns to the UITableView.
If you have a lot of rows to edit this can become tedious for both the developer and the user. As developers, we can create abstractions that make it a lot easier to edit different types of data in different rows. For users, there’s little to alleviate the back and forth of entering data.
In wanting to find a better way to present a table of editable values to the user, I began thinking about the new-ish UISearchController’s behavior. It overlays the UITableView when selected, moves to the top of the screen, and presents the keyboard. What if a row in the table did something similar when selected?
The video below is of a proof-of-concept I worked up. When a row is selected, a new view is overlaid that contains a label and text field mimicking the position of the row. That view then moves to the top, and the label and text field rearrange to be more friendly to data input. Touching ‘Done’ or touching outside of the input area (on the darkened table view) will dismiss the new view.
Quick testing shows this to work with UITableViewCellStyleValue1 and UITableViewCellStyleValue2. It won’t work with UITableViewCellStyleDefault since it expects both cell labels. It also looks just a bit weird with UITableViewCellStyleSubtitle.
Is this better than the back-and-forth of UINavigationController? I’m not sure. But this is, to me, more pleasant to use. It still feels like I’m in the same place in the application, instead of being whisked to another view.
This is fairly straight-forward in implementation, and I’d like to provide for text editing as well as values from a UIPickerView. In time I’d like to release this as open source through Water-Powered Ideas, but I want to work through the kinks first.
