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:
- Horizontal tabs (example), if there are a small number of panels.
- 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 -
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.
- 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-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.