I would go with this kind of UI, reasoning:
Users only select the dates that he/she is applying leave for without having to think about first day of leave and first day of work.
Leave balance is not displayed on the same screen as it might get too cluttered and might confuse the users. For "leave balance" checking, I would suggest to make it accessible from ...
In this case the meeting can act as two things: a reminder to do something that is not constrained by time and a start of something with no clearly defined schedule.
It could also be an oversight; in Glasgow we have ticket machines for rail that default you to buy 0 tickets which is really dumb.
When you think about exactly what the user is choosing, this makes sense (to allow zero minutes).
What you're really doing is asking two questions of the user:
What time do you want to schedule this for?
How much time on your calendar do you want to block off for this?
The answer to the first is the start time. The answer to the second is either a number ...
My answer is why not? Software is designed to enable users. Be cautious of making decisions, particularly ones that constrain users in ways you may not consider. There are many reasons why someone might use it: a reminder or a broadcasted note to others... who knows? (some research may find out)
In my experience, removing things like that because you ask (...
When it comes to UI/UX, "better or worse" is very subjective. There is, however, a standard for best practices: cater to your product, users, and target devices. What I mean by this in your situation:
If your product expects a date in the next week 90% of the time, design your date picker around that.
If you users require a larger interface to better use ...
Date selection isn't easy...
This has been a peeve of mine for a long time. I've not found a decent calendar widget.
Generally, I prefer calendars to scrollers because:
Using a scroller to select a date far in the future can be a real pain.
Calendars provide a lot of valuable context (today's date, day of week, physical distance to the date, etc).
In my ...
Should a calculator allow you to add zero to a number? My answer: yes. What's the use case? My answer: it doesn't need a use case. You don't remove a capability that "falls out naturally" and requires no effort to provide, just because you can't think why anyone would want to do that.
I’ve considered the question recently due to travelling and booking hostels. The same problem appears there, since whether you book the night or the day can be confusing indeed.
For usability reasons, the left one is a better choice since the user doesn’t have to do the maths. In this case, the best way to help the user is to be clear in the definition of ...
Any sort of open-house event might be well-served by this approach: people can accept and have a reminder added without it blocking out their calendar. The event may also have an end criterion that's not defined in terms of time. For example:
Title: Birthday Cake
Location: My desk
Time 13:00 tomorrow
Duration: 0 minutes
Extra info: Come when you like, ...
Using a slider requires the user to move a pointer back and forth along the line until they get the right age. The range is probably 0-100, and depending on its length, its resolution might be tight. I could get all pedantic about switching between keyboard and mouse and supporting users who have motor-skill problems, but I won't here.
You want an easy way ...
In my experience if you want them to focus on something, you need to make it as clear as possible. If you are looking to have them focus on the month, then you should focus on the month directly.
Comparing your two examples, the second one is far, far easier to understand, but I would definitely use the full month names, instead of dates. I think the month ...
If 90% of scenario is covered by Today+10 days, then perhaps something like this could work, without having to worry about Next | Previous or losing your current place.
It takes up more space, but it's also less finicky.
download bmml source – Wireframes created with Balsamiq Mockups
Today is indicated as bold. You also need month, because date ...
Combine quick input with clarifying comments
It seems a potential solution would be a quick method of input for general availability combined with the option of adding some clarifying comments.
download bmml source – Wireframes created with Balsamiq Mockups
If you're worried that users would feel that this is invasive, you could allow them ...
You shouldn't set a default for a birthday. Just as you shouldn't set a default for:
Credit card number
Credit card expiry date
The line of reasoning goes like this:
Usability is a measure of performance load, which is broken down to:
Cognitive load - the effort users expend when perceiving, interpreting and making decisions ...
The way Airbnb does it is great. When picking you would have the "First day of leave, First day of work" option. And when tapped, the calendar shows in an infinite scroll starting today and onward, in your case you could even color differently the days that don't count as leave days. They mark the leave days in the calendar nicely, even if they start one ...
The reason why the two calendar approach has been adopted so widely and is so convenient to use is because it is in sync with the users' thinking process i.e. when people go for booking a ticket, they know the dates for departure and return of their travel but are not often consciously aware of the duration of their stay. Making them state the duration (and ...
A standard date-picker is cumbersome, as you note, because you have to click backwards through years or get a gigantic dropdown with 100 options. It also assumes you care about what day of the week that date was on 30 years ago.
I had to tackle this problem a while back and came up with this solution:
My approach is outlined at http://www.ericstoltz.com/...
I think you've pretty much sold the duration idea, but I'm not sure how it would be quicker on touch devices?
Also, I'm not sure why there's a combobox for duration. It's an extra click and I'm not sure what's inside.
Perhaps you may wish to borrow some ideas from this design:
I'm sure you can do a better job on the colours.
On the calendar, you ...
The value of a grid (aka, calendar view) is it adds the context of the day-of-the-week.
If knowing the day-of-the-week is important, than a calendar picker will provide the user with a better experience. Trying to schedule a meeting next week? Knowing the DOTW is important.
Choosing your birthdate? DOTW is irrelevant.
So it depends on the particular ...
Have you thought about whether there is a preference for weekends / week days in the selection and highlight vs grey out the sections that are less important?
I think just a simple Next / Previous with a hidden calendar that can expand beneath it should work.
As per the comments here's a modified version, showing today:
There is no other more ...
In general terms the solutions either:
Let the user select an incompatible date
Not let the user select an incompatible date
The first group could let the user know the problem:
Mark the start date as wrong (I didn't see it in your screens)
Mark the end date as wrong
Mark both days as wrong
The second group doesn't have the first group's problems. ...
Having done some testing with screen readers here's what I've found works best for dates -
A plain text input with placeholder text showing the date format. Not all screen readers will read placeholder text, so in the past I've used something like a floating div for placeholder text for sighted users and ARIA attributes to provide a summary of the date ...
This is a bit of a "Apples to Toboggans" comparison.
Your first date picker with individual year, month/day/year selections is functional and will let you pick any potential date. (We can't tell from the screenshot but I'm going to presume you can't pick Feb 31st... e.g. there's some logic to filter the options to ensure validity)
In a typical scenario you ...
Which one is better
The one that fits the needs of the particular date better.
Context is everything.
If only the numeric date is important, your first option is nice. If understanding the particular day-of-the week is important, the calendar is nice.
Since age accuracy is not very important, you may want to consider the following layout.
I am assuming multi-device experience and I am assuming you want to support ages over 100 (if not, you can remove the last selector).
A drop down of 100+ elements is tough to navigate and select, you have to be precise with your scrolling
A slider - same ...
I feel giving people choices to edit hours, minutes and am/pm is much better option to have in your alarm and for this i think showing current time will be great.
Also, there is much better approaches used in Android using Google material design for setting up an alarm, that can be approached too.
Why not round up to the next full hour? You'd get all the benefits of defaulting to the current time with barely any of the hassle.
If the target time is within the hour, you'd only have to access the minute controls to reach your desired alarm time. I'd imagine that most people only set their alarms for events in the more-or-less immediate future (using ...
You can tell better but since you mentioned that 90% time the dates will be within next 10 days - I am assuming that the user pretty much starts off with a date in mind, rather than thinking which date to pick. So in essence he/she is clear with the date (which is approaching soon), and just needs to select what is in mind. With that assumption, check the ...