This is a nice start but i was confused how i should change my hour selection once i had made it. I was looking for an "Undo" button. Once i selected a minute value the component hid entirely, forcing me to refresh just to figure it out.
Rule of thumb: when designing components it is a good practice to ask, on every user click/keypress, "what happens if they made a mistake here?"
Not intuitive at all. Instead of the snazzy animation on the clock face after selecting hour, the animation should focus more on the hour vs. minute transition.
On Android, typically the dialog closes when one makes one's minutes selection. If I make a mistake, I typically just start over since it is at most one or two extra taps.
On the Web, I would expect the dialog to go back to hours after selecting minutes. Or to change colour to indicate that it is inactive and allow re-activating it with another click (starting again from hours).
I think this should always be the first question: how does my code behave on mobile? Considering that most (or a huge percent of) people are accessing the web on mobile now and that thos is targeted towards them, this is a kind of a blocking issue that would prevent me for using it.
My first experience with mini laptops was similar... the vertical space was very limited, and can't say how many times I had to zoom out to dismiss the takover popups on some sites.
Phone tends to be even worse, especially when zooming is disabled by a site, I get why, still bugs me though.
This isn't to take away from the awesome work of the OP, but Google has a library of React UI components based on material design, and a similar time picker is one of them - http://www.material-ui.com/#/components/time-picker
Oh wow, I haven't noticed that. I somehow assumed that you wouldn't be putting Google in your tagline if you were not associated with the company. Shame on me.
I use Material UI for a few projects, and like it a lot. However, before you rely on it, you should be aware that certain components have pretty horrible performance pitfalls that aren't immediately obvious until you have a lot of components on the page (or a lot of updates); they seem to be addressing some of them, though.
The thing I like about this the most is that is uses SVGs. This made me very happy! It's a very cool project otherwise too, and I can definitely see myself using it.
EDIT: Alternative would be to use HTML and CSS transforms or similar hacky techniques. So, I am glad to see SVGs gaining more popularity.
When opening the minute selection dropdown and the selecting time with the dial the dropdown disappears on mouseup instead of mousedown. The same happens when using the hour drop down. I think it should disappear once you mousedown on the dial.
Using the dial, you can sometimes start selecting or even drag/dropping some parts of the page. Use the css property user-select to prevent users from selecting visual elements that should not be selected. No one is ever going to want to select the text on your AM / PM buttons, so don't make it selectable.
Do people really prefer this over two infinite spinning number selection dials (one for the minute, the other for the hour) like on iOS?
I've designed and built a few of these. I've heard both sides of the argument (digital/analog). I find analog better in every way, but in my experience those who prefer digital time pickers are definitely vocal.
I've typically created a user config option in any app I've designed so the user can choose whether time pickers are digital or analog.
EDIT: I see that clicking on the numbers at the top pull up a dropdown, which I think is a nice touch. Designs in the past I've opted for a double-click or double-tap to activate the keyboard so user can type in the number if they wish.
I actually like the design of this much more than the default time picker on Android!
The AM/PM selection in is selector very clear - this is something I choose incorrectly every time I set an alarm on Android. On Android, the AM/PM pickers are inline with the time preview at the top - and you have to guess which one - blue or white - is the currently selected one.
Sure, if you stop and think about it, you can figure it out. This separate picker method in catc's selector seems much clearer in every case - especially when a user is in a rush or sleepy!
Personally I prefer a digit "touchpad" and 24h digital entry - just as for entering phone numbers. So "why not let me type it (on my smart phone)?" is a perfectly sensible question for me as well.
But see the comment above about pro-digital possibly being a vocal minority - we very well could be.
I suppose there's a big difference with never really growing up with analog clocks, and being used to relate to analog clocks for time keeping. All my watches were casio digital clocks, set for 24h display - similar with alarm clocks. I readily think in terms of 24h, not 2x12.
[ed: I'm also used to be able to tell the time by the sun for 24h two months in summer - 0100 being due north with dst (ironic, but true) - just as 1300 is south, 0700 is East, 1900 is West.]
This is neat, it'd be cool if there were support for choosing a time range from the same clock. I have that use case right now and I'm using one of those two handled slider widgets.
I personally find a prop to be a perfectly acceptable solution - you can define styles in your JS and share between components if need be. But I reckon there are folks who'd prefer passing class names to define their styles in CSS.
