Segmented/Split "Save | As" Button?

Question

Background:

I have an application that has several "Save As" options in addition to "Save".

This is a web application without a menu bar (just a button area at the top of the interface).

The ask:

Is it a good idea to combine "Save" and "Save As" functionality into a split button / segmented control?

^{download bmml source – Wireframes created with Balsamiq Mockups}

Seems logical enough to me, but I've never seen this pattern in the wild. What am I missing?

Answer 1

There's a good reason why this is uncommon (I'd say non-existant):

Consider this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

What happens when you press 2? Do you get 2? Or do you get 12?

The obvious answer is that you get 2, because the affordance of a button or a menu item is an individual action trigger.

Here's another example:

                        

What do you see first? Two irises or two eyes? Do the irises belong to the face, or are they part of the eyes, which belongs to the face?

The bounds of the button create a clear visual separation between Save and As. So you are creating separation to begin with, only to ask people to join the separated elements.

What your proposal does is force people to think and understand the (not immediately obvious) link between As and Save.

Consider the following issues:

• People who use calculators a lot may conclude that in order to Save as they need first to click on Save then on as.
• Why clicking on as equals save as but clicking on save is just save?
• If you add more buttons to the toolbar, you have to keep them in a distance from this segmented button, so people won't see the menu as Save as close.

The important point is that you are only gaining the removal of the word Save from Save as, but you introduce a possible point of confusion (non-conventional control) and you are taking away something that virtually everyone is accustomed to: a Save as... button.

My point is that there's hardly any benefit but quite a few penalties in you suggestion.

Answer 2

The split button can be a solution for you, only if you implement it properly. I'll try to clarify the idea:

The purpose of the split button is to add secondary commands that are logically grouped under a primary command. Examples are easily found on the office ribbon:

Use the split button in case you don't have much room on the toolbar, and you have many other buttons crowding it. Another reason to prefer a split button is that the secondary commands are not used often, or only by advanced user. This way, it doesn't stand in the way of everyone else most of the time.

The label of the button would be the name of the primary command. Next to it, there is only an arrow that opens a dropdown menu (don't use the secondary label "As"). In the dropdown menu show the secondary commands, like "Save As", or other types of saving:

^{download bmml source – Wireframes created with Balsamiq Mockups}

I tend to agree with the answers above that putting an "As" button next to the "Save" would confuse the users. It also deviates from the convention. If you stick to the commonly used design pattern, there is no reason users would misunderstand it.

See also Microsoft's guidelines on the topic.

Answer 3

I don't think splitting it into [Save|as] is a good idea. I have never seen such pattern, and I believe it is the same for users. So, I would definitely go for splitting it into [Save] and [Save as...]. I definitely suggest this one.

Another solution you might find interesting, though, is providing autosave with a strong confirmation as it is in Google Drive when you edit some document: "All changes saved in Drive". But in this case, the autosave should happen very often (like seconds after user finishes typing/editing whatever user deals with). Then, theoretically, you could have just one button saying [Save...] which would open a save as modal. But even then, having a [Save] button might make users less confused, because they would become more aware of the control they have on the saving process.

One more idea is providing a dropdown, in one of options:

• [File] that would expand to Save, Save as..., Rename etc.
• [Save ▼] which would save upon clicking on "Save" and expand to Save and Save as when clicking on the arrow down. This is similar to the pattern you proposed, but at least can be recognizable.

But as I said, I suggest having two buttons.

Answer 4

@Izhaki does a fantastic job explaining the cons. If you would still like to try (I'm thinking an AB test would be interesting, although i'm having a hard time formulating what you could measure as a goal), I think a button-dropdown combo is the way to go.

http://getbootstrap.com/components/#btn-dropdowns

It eliminates the potential for someone to accidentally click the "As" button and also affords you the opportunity to add additional File-like operations, like rename or copy.