I'm redesigning a product for iPad and Windows, and currently looking at the way buttons are placed in the application.

Base screen

Here is what a generic "base screen" looks like. Nothing special, just a navigation with some actions aligned to the right, with the content appearing underneath. The content is editable, so when you make a change to it, you must save it by clicking the save button. Auto-save beyond the scope of this.

 Modals

When clicking on one of the links in the navigation, a small modal will appear, which contains a form for editing.

Current design

Currently, you fill out a form or edit it, then you either accept or cancel your changes by tapping on two icons in the top-right of the modal. This has a number of immediately obvious limitations:

1. Icons are ambigious and should be accompanied by labels to clarify meaning
2. A destructive action (cancel) and constructive action (complete) are styled too similar (given the same level of prominence) and placed too close together
3. Actions appear after the form, so the user fills out the form from the top to the bottom, only to return to the top to action it.

Proposed design

1. Icons are replaced with buttons that clearly specify what each action does with a label.
2. Cancel and complete buttons are separated and now styled differently, most importantly: the destructive action "cancel" is styled only as a link as opposed to "complete" which is now a button. This will hopefully encourage form completion as opposed to cancellation.
3. Actions are now at the bottom of the form.

The problem

It has been pointed out that it seems strange that for the base screens we have our actions before the form (the save button which saves the content below it) while on my proposed design for the modals, they're at the bottom.

I see his point although the reason for this is simply to conserve space. What these wireframes don't reflect is the amount of content we're having to fill into such a small place, so aligning the save button to the main navigation makes sense. If we didn't do this, we'd have to sacrifice our content area instead by including a new row to accommodate a save button and maybe one or two more buttons in the future. Hardly seems worth it.

My question is this: has anyone else encountered this problem and what did you do about it? Is my proposal OK considering this inconsistency between the button placement on the base screen and modals, or does it really need to be fixed?

Limitations

• User testing right now is unfortunately beyond scope.
• Has to work for touch as well as mouse.