Nowadays I'm working with Primefaces and I have to choose between two date input controls from here: Popup vs button.

The difference:

When clicking on the "Popup" text input, you are able to type the date and ALSO the calendar shows so you can select the date from it.

When clicking in the "button" text input you can only type and if you want to select from the calendar, you have to click the button to open it and select.

I think the one with the button is more clear about the expected results and specificity of the action, but the one without it gives the same functionality (I think the level of confusion that could bring is minimum because there's just 1 input and 1 final action) so I'm not sure about the button being really necessary.

Is there any reason why I should consider one over the other?
Have anyone tried it with users and noticed any difference?
Is there any study on the subject?

4 Answers 4


I think you have almost answered your own question.

  • The button approach does a better job of conveying how the widget works, because it conforms to expected idiomatic behavior for the text input and the calendar button.
  • The popup approach has a clearer entry point (only 1 control) and requires only 1 click (vs potential 2) for the user to see both input options.

To choose between the two, just figure out which qualities are going to be most important for your users.

  • If the widget is going to be used frequently, used by experts, or used in a dense form where extra buttons will throw off grid alignment or add clutter, the popup approach may be better.

  • If the widget is used rarely, used by less tech-savvy folk, or used in situations where popups conflict with site-wide UX principles, then the button may be better.

Nowadays I generally prefer the popup approach, because:

  • It's faster for expert users and for novice users
  • I would rather have one clear entry point into a widget than two entry points (button or input) which causes more cognitive load because users have to pause to choose
  • A helpful placeholder or label (e.g. Type or select a date (m/d/yy)) can inform users that they can either type or select
  • Popup date controls are increasingly familiar to users thanks to their popular use on calendar and travel sites

...but that is just my own general bias. It's more important to figure out what qualities are going to be helpful for your case, hence the tradeoffs above.

Hope that helps


That example you have gone with isn't ideal really. I would look at this from the perspective of how the user is interacting with the field.

Take a keyboard user for instance. If they tab into a field then it is likely they will be expecting to manually type into that field. If the calender popup also appears, provided it isn't obstructing the form itself then it is up to the user how they select the date - typing or moving to the mouse and selecting it there (it doesn't look like the calender is keyboard-accessible in this demo).

However, if the user is using keyboard and tabs to the calender button itself and triggers it, then you can assume they want to use that calender option with their keyboard. In which case the focus should switch to the calender and allow them to pick their date using the arrow keys.

That example doesn't really allow them to do that so it isn't one I'd go with myself.

Personally, I would take the field+button approach and if the user selects the text field (with either mouse or keyboard) then you put the cursor focus in there so they can start typing, and if they select the button then you transfer the focus to the calender popup.


I would suggest the 'Button' option however both have their own benefits and weaknesses.

Reason against the 'Popup':

  • Firstly, if you tab into a field rather than click it and a drop down calendar appears without your requesting it that can be distracting.
  • Some users would prefer to type only and would rather not be confronted with a secondary input without choosing it. Whereas you'd be unlikely to alienate anyone by making them click a button for a secondary visual input option.
  • Not ideal for touch (see below for why)

Reasons for the 'Button':

  • No surprises, users are often anti-popup even when they're helpful shortcuts.
  • Users have the secondary option if they'd prefer and it's a recognisable enough UI element so won't cause confusion.
  • Touch screen friendly, if a user clicks on the button they can use that option whereas on the 'Popup' if a user clicks on the form field their keyboard will appear and they will zoom in on the field and thus potentially obscure the calendar partially or entirely which will feel scrappy.

I've tried to break it into for and against to explain my reasoning behind the choice of 'Button' rather than weighing up the benefits and problems with both.

I wish we used Primefaces where I work, everyone is stuck with Richfaces and it's a pain!


The best wuold be if open by the button wouldn't disabled the input, but if it's not possible... I'm defenitely for the popup.

When I use the calendar widget, sometimes I select the day on the popup and then change the year by keyboard. This is much important when you are asking about birthdate, then travelling date for example: in the first case, blocking input I'd have to click various time before I could find my year of birth, in the second case I can handle that I have to skip next months: so what date you are asking for is a point.

However I think that it's common now to see a datepicker acting like this, even without the button and the users knows how to use it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.