User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I am design a "Setting" form for a Windows application (Winforms). I'm doubting if I should place an "Apply" button 4 times on the same form.
On the first hand, each button refers to a separate section in the form. On the other hand, it may confuse the users, so should I use only one 'Apply' button that refers to all the panes?
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:
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:
unchanged, changed and saved, changed and not savedIn short:
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)
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)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.
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.
I would say, place a simple Apply form and trigger all the different sections such that, form data will be saved with one single click.
In the UX perspective, this is purely bad design. Making multiple apply buttons available doesn't make it good UX to an end user.
I hope that clarifies your query..
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 :)
You may add one bigger and more prominent "Apply" button with a fixed position.
Discussion about Submit button in form.
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.
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.
Sometimes it's easier to come at it from one of the edge cases.
What if a user opens the dialog, makes a change to the first section of information, then clicks on APPLY in the lower right?
What would happen?
I can see scenarios where you might have to warn the person that they changes a pane of information, but didn't click the correct APPLY button.
I think at that point, it becomes much clearer as to why 4 separate apply buttons is a messier solution than having just one apply to all of the panes as a group.
