Pull down buttons (if that's their official name) are starting to pop up here and there. For example, if you look at Eclipse it seems that almost everything is a pull down button. Personally I find them misguiding, since the action they perform is sometimes context sensitive, sometimes it just executes the first action on the pull down list, etc.

When is it okay to use a pull down button? Personally I'm having a hard time justifying their existence.

4 Answers
4

You got to consider design conventions for different platforms , In this case these buttons can be seen in tools like eclipse and photoshop which is used by users who are not new to computer.
These tools has many options which has to be grouped under single name , it was like this

File Edit View

As the tools got more advanced with so many options that led to not enough real estate for the users to work with , even the " File " "Edit" "View" were changed to small buttons.
Its perfectly normal to use, Even few websites are trying with these buttons . Eg dropbox

So you're basically saying that they're tools for experts? I.e. tools for people who are going to spend large amounts of time with that particular tool/software? At least, that's pretty much how i see it myself.
–
Juha HollantiFeb 25 '12 at 18:48

Ya and this is happening mainly cause of the real-estate issue. Tools for experts should also be very user-friendly and effective.
–
Pratheep chFeb 25 '12 at 19:49

I'd suggest that these are commonly used in two different circumstances, one good one bad.

The first is as a poor mans replacement for a genuine menu, often used because of a lack of screen real estate.

These show up in a number of applications and do tend to be confusing to users when first encountered. They are managable - users can learn how they work - but they're not as intuitive as other controls.

An example of this is the toolbar at the top of a Resharper "Find Usages" dialog.

The dropdown buttons here are being used to configure the display. Space is tight, but I never can remember where an option is when I need it.

The second situation is where a related but rarely used function is needed - most of the time users simply press the button and can ignore the dropdown, but when they need the related function it's readily available.

An example of this second case is the Add Existing Item from Visual Studio.

Most of the time users just press Add and it will do exactly what they need, but they can easily "Add as Link" if they need to. Promoting "Add as Link" to a button on the main dialog would only clutter it up with a very rarely needed option.

Pull-down buttons are workable when the user can either perform one action or several variants. The typical example is 'Save', with 'Save as...', 'Export...' and 'Synchronize' as alternate options.

The advantage of pull down buttons is that they're very space-efficient and work well when the default, shown option is the most likely use-case (one good practice is to remember the user's last choice on this menu, and set it as default in future). Unlike menus, users don't expect them docked to specific locations on a page, and they don't force a click-find-click workflow for commonly used actions.

Pull-down buttons also make their content immediately discoverable. A menu named something vague like 'output' might not make much sense, but by making the label one of the actions, like 'Save as...', it becomes clear exactly what sorts of things the controls do.

But pull-downs can be used poorly, too. The options within a pull-down must be variants on one another. I can guess, as a user, that the variant to 'Save' is 'Save as...'. I cannot guess, however, that a variant is 'Rename', 'Delete' or 'Copy'. In that case, the content of the pull-down would be even less discoverable than items in a large menu. Not good.

The other issue is that it must be clear the element can work both as a button and as a menu, and obvious how to operate it as either. Pulldown segments need to be large and visible, and the UI must be able to forgive me for accidentally clicking the button when I meant to open the menu (both through undo functions, and letting me uncommit a click before I release the mouse button). It must also be apparent which buttons are and are not pull-down, and I should be able to click the pulldown as a simple button, or else I will be very frustrated when I click my 'button' and discover I still have to navigate a menu.

Because pulldowns are oftne implemented when screen estate is in short supply, designers create narrow icons that often violate the above cautions. The result is an annoying, frustrating workspace, where the reactions of the UI are always in doubt. Not good for an error-sensitive context like an IDE.

Don't mess with defaults. I hate when software does that to me. Defaults should remain the same regardless of my last choice. A default is a default for a reason (like most likely to be chosen) and should not change just because today I happen to select something other than my default. Changing my default like that most certainly is not a best practice.
–
Marjan VenemaFeb 25 '12 at 10:06

Some of these controls are especially frustrating in Eclipse, because they don't exactly work so that you use the pull down button to select, for instance, the first item in a list. Instead in Eclipse, if you click for instance 'Run' command it's context sensitive so that if you happen to have something highlighted in your text editor, which can be run, it will run that instead of executing an op from the list.
–
Juha HollantiFeb 25 '12 at 18:45

@MarjanVenema - it depends on the type of control and the context, and the costs of a user making an incorrect assumption. There's also a difference between changing global defaults and 'remembering' the last action used within an individual session. It's a matter of discretion.
–
Jimmy Breck-McKyeFeb 25 '12 at 19:19

I guess we disagree :-) At least in so far as it is a matter of discretion. I do agree though that whether the control should stick to its default or should remember the last action used, depends on the info/action/type of the control. For me: menu or toolbar controls should stick with (app's) defaults, stuff that is less location dependent and more like settings c/should remember last one. Maybe the distinction should be whether the value of a control on first time use is the default (what it would be if not specified at all) or just the initial suggestion. Some more thinking to do...
–
Marjan VenemaFeb 25 '12 at 19:46

Group of items that needs to be stacked under one roof. Pull down menus are to pick an item from similar set of items. Other way to look is at the real-estate space that it can control against any other forms of patterns. It also wisely says to pick one option.Now this pull down is well fashioned in the MS 2010 Version where "ribbon strips" make it much easier to pick the immediate or most required items. And still it has a arrow tucked neatly to pull over similar items, so this is an extensible pull down which is camouflaged.