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.


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

2 Answers 2


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.

  • Good points, added some contextual information to the question. *** A row accessory is already used for a disclosure indicator, so the same row cannot selectively trigger (both) selection and modification. *** The top-right "+" button already triggers its own popover, so I would have to go for a somewhat unattractive (?) "cascade" of popovers. *** My UX priority is ease-of-discovery: the top-right "+" button seems more explicit than multiple-tap patterns, gestures or a special "+" table row.
    – Gary
    Jul 9, 2014 at 13:28

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).

  • 1
    would you mind posting a screenshot or URL?
    – Danger14
    May 30, 2017 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.