Warning: Long answer! In fact since this got migrated from Graphic Design to User Experience it's two answers in one: first, a UX style "What UI conventions should I consider?" then a GD style "How to go about solving X type of awkward design problem?" for the one possible difficult case where existing common conventions don't fit.

First, keep it simple. I'm assuming there are good reasons for wanting the unusual, complexity-increasing feature of being able to save different parts of the form independently. If there isn't, don't do it.

Second, if you can use an existing UI convention, do, for many reasons including familiarity, maintainability, and the fact that they will have already been through more testing and refinement than you or your employer can realistically do.

If a user doesn't need to be able to see options of different types side by side at once, and if the elements behave independently as distinct sub-elements, make them into separate independent but linked sub elements. For example:

Vertical tabs (example) if there are a large, or potentially large (re-configurable) number of panels.

If horizontal space is a constraint making vertical tabs an unattractive option, and there is a (potentially) large number of tabs making horizontal tabs not an option, an accordion ( example ) where opening one tabs closes others may be the best option. It uses space more efficiently, at the cost of potentially forcing the user to do more vertical scrolling.

If it needs to be possible to switch tabs before saving, consider clearly marking unsaved tabs somehow. You'll likely need this if changes might be complex (working memory capacity is about 3-5 distinct things: if user operations are complex enough that operation 3 might max this out, they may forget what changes they made where in operations 1 and 2), or, if you need to allow users to save each tab separately. Re presentation: don't unthinkingly copy the convention in professional desktop software of simply appending a small * to the tab title unless you have reason to expect your users to be familiar with that specialist convention too, or you've tested it and in your design the * really does stand out clearly.

If switching between unsaved tabs is necessary and you need each tab to be able to be saved separately, don't forget to make explicit that each tab's save button only saves that tab. One example easy way: label them "Save [tab name]", within the tab wrapper, then directly below, outside the tab wrapper, have a button "Save all tabs" just the other side of the tab wrapper. How well this works will be a factor of how clear and concise the tab names are and how clear the visual demarkation is between inside and outside the specific tab.

If panels may need to be viewed side by side some of the time, a compromise solution using accordions set to be stay open until specifically closed or saved could be used. This gains flexibility at the cost of some usability - uses could find themselves lost on a page with too many open accordion panels. Usability versus flexibility is a constant issue in UI design (see link below) and you need to know what the ideal balance is in your case.

If the above compromise is too big a usability cost: An alternative could be, a button in a standard accordion to keep a panel open. Pin icons are often used to communicate "This button makes this element stay where it is when you do other things". This alternative lessens the usability cost above - people will only be swamped by panels if they have chosen to be, and the icon can be as subtle or obtrusive as you make it - at the cost of some users potentially not noticing the feature is there (so, a lower cost to usability, but not all users will get the flexibility benefit).

Now here's the original answer which assumed the asker already knew about common UI conventions and had already established that they weren't suitable in his/her case.

Conventions should be applied when suitable, but not shoe-horned in when they don't fit. To mis-quote Einstein, make it as simple as possible, but no simpler.

If there's a functionality-driven reason why you need seperate apply buttons... (for example, maybe it's some advanced tool where the options are independent and people need to be able to see the results of applying one set before they commit another, and they need to see all the settings at once)...

And you want to find a way to counteract the UI confusion other answerers have described, without dropping the feature...

Then you've got an interesting UI design challenge. The problem is essentially:

Each panel has one of three possible states - unchanged, changed and saved, changed and not saved

People familiar with simpler interfaces may expect that saving one panel saves all the others.

Therefore, users will have a tendency to see panels that are changed and unsaved as being saved, when they aren't.

Four panels' independent states is a lot of information for people to keep in mind at once. Generally speaking, 3-5 is the maximum number of independent things you can count on people being able to keep in mind (working memory) at one time while focussing on another task.

Therefore, even when people know that saving one panel only saves that one panel, when they are focussing on the complex details within one panel, you should expect users (including highly skilled users) to forget the save states of other panels.

In short:

New users won't get the result they expect

All users' memory capacity will be pushed to the limit

That's a serious problem. Simplifying the interface to just have one save state is the best option, but, if there's a good reason why that's not an option, it's not a completely unsolvable problem.

You need very clear, explicit, un-ignorable visual cues about the save state of each panel, and, about precisely what the scope of each button is.

There are loads of ways of doing it. Off the top of my head, here's one suggestion:

(since this has been migrated from a graphic design site to a UX one, it's worth stressing that this is intended only as an illustration and possible starting point for design work and testing, not a ready-to-use complete solution)

When changes are made within one panel, the panel's background fades to a mid-yellow colour. Yellow is a good choice because a) it's a common convention used in 'Notice' signs, signs that mean "Everything's okay but pay attention and be careful", and b) it's the colour that is perceived as being lightest relative to its value. The stronger a colour here, the more likely it is to be noticed, but the more likely it is to harm the readability of the form text. Yellow hues give you the strongest colours while losing the least contrast with the black text. Make sure that this shade of yellow is consistently used across the interface to signify 'Unsaved changes', or similar notices.

When changes have been saved this session, have a very different visual cue. I'd go with:

A green 6px border-top on the panel that has been saved. Green is commonly used in interfaces to signify success or things functioning. (other than that, this is purely personal taste)

An indicator animation spinner that shows within the panel that is saving in a consistent location (e.g. top right corner), which is replaced by a clear notice saying "[tick icon] Changes to this panel saved" or similar.

All the above to fade out when changes are made in that panel - each panel should only ever have one state indicator at a time.

For the benefit of new users, each button should explicitly state that it only saves the changes in that panel. I'd go with a 'belt and braces' approach doing this two ways:

Instead of 'Apply', label the button with something explicit like 'Save this panel', or, better still, 'Save [name of panel]', so each button is clearly different in function.

To make sure this can't be mis-interpretted, on mouseover over the button, the panel it refers to is highlighted in some way. Maybe temporarily give it thicker border-right and border-bottom so it appears to be raised from the page, and maybe fade the other panels to something like 40% opacity so it's clear that this is scope we're talking about, and those aren't what we're talking about.

These should go most of the way towards solving the two problems, of new users' expectations and experienced users' working memory capacity.

Clearly, changes like the above are going to result in a more complex interface. They should only be considered if, in the ever-present trade-off between flexibility and usability, you're leaning towards flexibility and power, over usability and simplicity (e.g. if it's an enterprise tool to be used by professionals). But, if you're careful about how they are applied, they can be made to be fairly unobtrusive, and have a small impact on usability and simplicity. But there will be an impact on usability and simplicity.

This is an outstanding answer and I wish I could give it more than +1.
–
Lauren IpsumDec 21 '12 at 13:18

I don't really agree with this. It doesn't seem like a normal convention for software. Doesn't it make more sense for each of these boxes to be divided as a separate settings page which could easily be navigated by tabs?
–
slawrence10Dec 24 '12 at 0:01

@slawrence See the first paragraph: "If there's a functionality-driven reason why you need ... [independent settings] and [users] need to see all the settings at once". If it's a conventional problem, use a conventional solution. My answer was intended to show how, if it really is an unconventional problem, to begin developing a problem-specific solution. Obviously, if it is a common problem, it's better to choose a conventional solution.
–
user568458Dec 24 '12 at 15:06

I've edited in a UX.SE style answer to the start of the answer. Apologies for the length, as it's now two detailed answers in one... The "what convention should I use?" UX answer and the "no existing conventions fit, how can I design a functional solution to my awkward problem?" GD answer.
–
user568458Dec 24 '12 at 16:17

I think that while for many of us on this site it's easy to understand how this works. To a normal user, it might be quite daunting and confusing.

I would suggest sticking to convention by separating each of your boxes into its own tabbed page within settings. Let's look at some other software that does this:

Skype

Microsoft Word

Notice that in both of these examples they use one "Apply" button ('Save' and 'OK' respectively) that is located outside of the pane of the currently viewed tab. When clicked it applies ALL changes across ALL panes within settings and closes the box.

Another way you could go about this, is just one really long, scrolling pane, alike to Spotify and Chrome. Interestingly neither of these examples have an Apply button. I think that this method is more appropriate for "web based" apps and so less suitable for your own program. But lets have a look:

Spotify

Chrome

My suggestion would be to stick with the first implementation, alike to Skype and Microsoft Word, seperating your boxes as seperate tabs within a settings dialog box. One "Apply" button updates all changes, and is clearly outside of the current pane, but within the Settings dialog box.

This answer assumes that the two features that make it a tricky UI problem - separate save states, and side-by-side settings - can be dropped without harm. If they can be dropped, then it really is as easy a problem to solve as you describe. +1 for the clear examples and the note on the importance of the placement of the apply button. But I'd be surprised that it was a question at all if it was really this simple a problem. Then again, I'm often surprised!
–
user568458Dec 24 '12 at 16:29

You have a lot of information on that screen. Users making only small changes in one pane may need a little longer than is desirable to locate the button. However, since there don't appear to be any dependencies between the panes, individual buttons are not a good answer.

I see two usable solutions. They are not mutually exclusive.

Upon making a change, the Apply button would be highlighted in some way (change to orange or some such color).

You could repeat the Apply at the top and bottom of the window to help it break through the dense information.

If you feel that your particular users may need a little stronger cue, you could change the wording as well: APPLY ALL CHANGES. That would make the action clearer and make a larger click area.

I don't think it makes sense from a UX point of view. Yes, they are separate actions and categories but it's still one form. If you want to be able to apply the actions separately, I'd suggest moving the differing forms into separate views.

Having 4 apply buttons is, to be honest, a nightmare. It's confusing and people may forget to click on one.

So either have one "master apply" like most apps have, or separate the 4 categories into their own views :)