In an application, the user is able to edit the information of several objects. The user is able to save and go to the next object.
What is a good order for this buttons?
A good order is Previous, Next, Save and Close.
Break the actions apart. If you're providing Save and next why not also provide Save and previous, and then also Next without saving? If I press Cancel then how do I close the window? Do I need to press Save and close, or *Cancel" also going to close the window? Does it just close the window without saving, or does it override my last save?
Keep it simple, let the user save when they want to save, and navigate when they want to navigate, there's no need to combine the two. Yes, it saves a click, but it makes the UI more complicated and the actions more difficult to understand. "Wait, should I press Save and next or Save and close? Let me think about it for a second and decide what I want to do now..."
A clear indicator that there are more »objects«, that need to be solved can be mixed with a progress bar, that gives a clear feedback. You could also add some sort of progress number in % at the right end of the progress bar.
I don´t think that you should use additional tabs here. If you really need them then you´re asking for too much information. No one wants to use a system where you need to fill in data for an hour, before you can make full use out of it. In the case there is that much data needed, then ask it on demand and inline.
Generally you don't toggle tabs with prev/next -buttons, you merely choose the tab you want by clicking it.
In addition to this, if you would chose to stick with the prev/next -buttons, I think there are some flaws with the consistency in this UI. The buttons "Previous" and "Next" should have the same semantic meaning, only mirrored. Here the next button however also implies that any possible changes will be saved, something that the previous button doesn't. This is confusing.
If you have previous and next buttons they should be just that, the "Save" button should be separate and save any changes on all the tabs.
There is a "Cancel" buttons and a "Save and close" button, what do you do if you have made changes that you don't want saved and you want to leave the window? Do you click Cancel -> Save and close? Or does cancel close the window also, even though in its context it implies it doesn't?
Finally, the Save/Ok button should always be displayed in front of the cancel button, especially if your application is mainly intended for Windows users.
Personally I would set up the button panel as such:
Nothing more, nothing less.
We have a similar application and after user testing found that the following works best:
Instead of using Previous and Next, labelling the actual destinations gives the user a sense of where they are. There wasn't really a need for a discrete Save button since the green buttons performed the save anyway. We didn't find it necessary to include a Cancel button either since most users would just close the tab.
I don't know why you need "apply" if you have "next" already written. Next imply's that you are applying and moving on. The next button should be on the bottom right prompting the user to move on to the "next" set.
You could have a "back" on the bottom left if the user wants to go back and edit the previous screen. But using "back" and "next" are the most common terms and the most widely accepted.
As far as "save and close" or "cancel" go...not sure you need a "cancel" if the user wants to quit they will just close the window or go back enough to where they can do something else on the site. "Save and close" only applies if the user has a username and password to be able to get back in and continue filling out the form.
If they have the ability to log back in, the "save and close" button could be located to the left of the "next" button. You want the user to finish and move on, so "next" should be the easiest button to find in order to steer them to the next screen.
Principle.... why users can not always decide when they want to save data? See comment of @vitaly
Ok, a possible approach for your scenario: You don't need a Cancel-Button because data will be saved when you go to the next object. You can only discard changes of the current object. When you go to the next object show the user that settings were saved.
I would use following button order and naming variants:
[ < Previous ] [ Next > ] [ Save and close ] [ Close ]
[ < Previous ] [ Next > ] [ Finish ] [ Close ]