iOS: table view “Close”, “Edit” and “+” button placement in a navigation bar

Question

There seems to exist some ambiguity when a table-based, multiple-item view needs to combine navigation ("Close"/"Back"), editing mode switching ("Edit") and aggregation ("+"/"Add") in a single navigation bar.

Apple seems to avoid the issue by inserting a dedicated "Add" row inside a table view and placing the "Edit" button either at the left side of a navigation bar (in case of a root view) or at the right side (?) of a navigation bar (in case of a stacked view).

I dislike the idea of a functionality-bound row in a table view that users have to hunt for all over the entire table and the "Edit" button changing positions within a navigation bar.

The solution I am considering is more than one button in a navigation bar, either: 1.) on the left side, ["Back" | "Edit" ---- TITLE --- "+"], or 2.) on the right side, ["Back" ---- TITLE --- "Edit" | "+"].

Context: a table view with editing-mode toggle capability (analogous to, say, iOS 7 Clock >> Alarm -s). In non-editing mode, a row tap means selection, "drilling-down" on that row, as suggested through a disclosure indicator (a row accessory). In editing mode, a row tap performs row modification, a row "-" performs row deletion.

Thoughts?

Would you vote for (1.) or (2.)?

Answer 1

It is a bit tricky without the context - a sketch would help, but in general I would not recommend having three buttons in the navigation bar. Partly because it might take up too much space, depending on how you are planning to design the buttons and partly because it would "feel" inconsistent according to the UI guidelines.

If I should choose between your options I would go with number 2. Top right corner is generally reserved for actions relating to the current view. Top left is reserved for navigation.

I know it is an extra step, but I might consider making a single button in the top right corner that triggers a pop-over with the option to edit or create a new.

Additionally I am think whether you could maybe reserve the top right corner for adding new items and then maybe embedding edit in the table rows instead? What does edit mean? Do you get to edit the entire table or just a single row? You know the pattern where you can select a row by pressing anywhere and inspect it by pressing an icon in the right side? If not see the Wi-Fi network tab on iOS. It is not my favourite pattern, but it might help you here.

An entirely different approach could be to look using gestures instead. Gestures tends to have the problem that people forget to provide enough visual cues to create an affordance for the gesture, though. So look out for that.

Answer 2

After much soul-searching and many mock-up screenshots, I have to agree with funkylaundry that more than a single button on the same side of a navigation bar looks non-standard in an iOS application.

Thus, I decided to stick with Apple's idea of a functionality-bound "Add..." row inside a table view, in a separate "+" section at the bottom of it (which seems to be most common). The bottom-most placement might require scrolling more than a screen-ful to even notice the "Add..." row, so the UX problem of poor ease-of-discovery remains unsolved. The secondary problem of having to "hunt" through an entire table view for the "Add..." row can be lessened by using a right-most "index bar" with a "+" trigger button at the bottom of it, allowing for convenient single-tap scrolling all the way to the bottom.

An alternate solution would be placing the "Add..." row at the top of a table view (followed by data-specific sections and rows). The top-most placement can serve as an immediate clue as to the functionality available through a table view editing mode, prioritizing UX ease-of-discovery. However, the downside is the fact that a table view representing a list of items looks somewhat "artificial" with the "Add..." row right at the beginning of it. (I might be switching to this approach in the future, anyway.)

An entirely different solution would be a graphical "+" button (instead of the "Add..." row) on top of a table view that does not scroll along with the view itself. However, such a "floating" button might obscure row content or row delete/move buttons, so it might turn out cumbersome.

On a philosophical note, toggling a table view editing mode does NOT seem to be an application-specific command that should require a user-defined "Edit" button anywhere, but rather a change of an innate property of a table view. iOS Human Interface Guidelines (HIG) should perhaps acknowledge this distinction, through, say, a dedicated toggle button embedded somewhere within a table view itself, or through describing and allowing the specific use case of more than a single button on the same side of a navigation bar ("Edit" and "+" buttons on the right).