Closed geordee closed 9 years ago
Once something is tagged as future
it is an accepted request and just needs to be assigned and/or implemented. We don't need anymore +1
or other supportive comments please. They end up causing more noise and distraction than anything else.
EDIT: This was in response to quite a few +1 comments which have since been removed since they are unproductive. However, since we veered off-topic here to explain the situation of how to get notified, the following little discussion is being kept in place since it is useful even though not directly related to the issue at hand.
I think +1's are also more like "/subscribe", this way they get further email notifications for this issue :)
They can just watch the issue... Notifications header to the right of issues. Click subscribe, boom. Then no emails are going out to everyone else.
Do you mean this? :D
The thing is you either subscribe only to issues where you participated (what they are doing with +1s) or to all issues. But in the latte case there is a lot of noise, there has been around 100 issues filed in the last 48 hours alone :D
If there is another way which I'm not seeing I apologize for still being somewhat a GitHub noob :D
:boom:
Yea, no worries, very little known feature. Tbh, GH issues are the suck for stuff like this, so I'm just trying to make due the best I can to keep things organized and reduce noise.
Wow I missed it somehow :smiley: Thanks and sorry for arguing about this. Now I can help you. Look:
Developers, we really value your opinion.
but...
+1
Use this button instead:
:smiley:
haha, don't worry about the arguing much. We are all still getting the hang of how this should be managed.
The thing is, we don't get "How many are notified" numbers for the issue. So it isn't really a +1 level kind of thing were maintainers see it. But, +1's don't add anything to the conversations we have at all, they are pure noise. Each issue is major. With additions, we need to weigh whether it is truly worth being in core for everyone. At the point where +1's would change a decision, they just become too noisy.
These are at least my thoughts on it, others on the team may disagree or feel the +1's can be useful. But we can debate that out-of-tracker and come to a conclusion. :smiley:
Uhm guys? relevance pls ;)
On Wed, Jul 8, 2015, 17:56 Jonathan Garbee notifications@github.com wrote:
haha, don't worry about the arguing much. We are all still getting the hang of how this should be managed.
The thing is, we don't get "How many are notified" numbers for the issue. So it isn't really a +1 level kind of thing were maintainers see it. But, +1's don't add anything to the conversations we have at all, they are pure noise. Each issue as major. With additions, we need to weigh whether it is truly worth being in core for everyone. At the point where +1's would change a decision, they just become too noisy.
These are at least my thoughts on it, others on the team may disagree or feel the +1's can be useful. But we can debate that out-of-tracker and come to a conclusion. [image: :smiley:]
— Reply to this email directly or view it on GitHub https://github.com/google/material-design-lite/issues/782#issuecomment-119659416 .
Sorry @surma, that did get sidetracked a bit by trying to keep discussion in context... It's all done now.
In the meantime, does anyone have a good date/time picker that integrates well that they are using?
@mikeal The obvious choice I guess would be http://materializecss.com/forms.html#date-picker but I can't say I've tested it for clashes etc.
@mikeal try this one http://material-ui.com/#/components/date-picker
@mikeal I wouldn't choose one of them.
The suggestion from @slugmandrew is probably one of the first CSS & JS themes which realized the material factors, but is basically not optimized written. I didn't looked anytime into the code, but alone the case when you scroll on a demo page and its basically laggy, i would never use it.
The suggestion from @Smotrov seems more positive, but it seems that there isnt much time spent on, seeing directly CSS mistakes in the first seconds of an element, is giving me a bad feeling about the code which is used. By looking into the HTML, my feeling getting worser and worser about that. Having only inline CSS isn't the way producing good software :see_no_evil:
I suggest you use jquery-ui without any theme, i used to require a datepicker myself today, and i choosed to create my own CSS. With jQuery UI you are at least safe about the code quality behind it. The CSS is basically simple and took me only 5 minutes with 10 selectors,
@Grief-Code Sounds great, why don't you share your code in a jsfiddle? Some of us are not that great at css :confused:
Also, the suggestion I made runs perfectly on windows chrome, and the datepicker prevents you scrolling when it is popped up.
Unless the discussion has to do with how MDL should implement the functionality, please avoid having the conversation here. It is distracting to people wanting actual updates on the functionality to have all the extra chatter going on.
Thank you!
Materialize datepicker is a modified version of pickadate but more than a year old and no plans atm to upgrade. The solution I would like to see in MDL would be to re-use one of existing pickers and re-style with Material Design. The internal design should be flexible, so that users could exchange the default picker with preferred one, with custom styling (or implement custom styles), without big efforts. This would make the Bootstrap to MDL migration easier, at least in regard to datepicker.
So much time passed and still no datepicker. For some simple working release to have tool already one coder, one tester, 3-5 days max. But no, you need team of 50 ppl and 3 months eta for datepicker...
@mibcadet I know it is frustrating to see a big demand for a component like this and not see any progress, however, I’d like you to consider the following things:
As I said, I understand your frustration, but I promise you that we are doing our best to advance MDL as fast as possible without degrading in quality.
@surma "We need to consider a11y" - Make it work, make it usefull, make it stable, make it beautiful.
I could agree with you if when it would be marked as an alpha or beta. Due to this package and awesome MD specs I have started using it and really appriciate your work about MDL. Up to this day I did not need datepicker and I did not even realise it will be so big problem. So I have searched through issues then I saw: "addyosmani added future feature-request labels on 7 Jul". 7th JUL! We got October now and not a sign of update about that. Then I realised I lack a so basic feature. Now I got to ask: to rework my 3 projects to another framework? Or I should wait updates? Or add custom packages and risk they will crash some compatibility?
If you are 4.5 people and it is not enough maybe you need to hire more?
Good luck anyway and thanks for response!
@mibcadet Datepicket is far from a "basic feature", on the contrary it is one of the most complex. I am also missing this feature along with many others features, but I really appreciate what they have done so far. I prefer to have this limited stable framework than have a most-completed-buggy framework. Your temporary solution can be as mine: use a custom package for the missing feature until they made an official one.
@stunaz What custom package you use? In my words "basic feature" did not mean simple but very important and must-have. I agree it is quite complex thing. Anyway 2,5 months no update about that seems bad.
I haven't been working/using the datepicker yet, you can use http://jqueryui.com/datepicker/ as a simple one. But you will probability have to work on the css
@mibcadet I agree with you that it is a little disappointing to see such an important feature missing in MDL, more so because plenty of relatively less practical, less essential elements were included in the package, but please try to be respectful with the people working on this project. Allocating resources and employees to build this great thing that you (don't forget) get to use for free won't have a strong commercial priority for Google. They're also not full-time dedicated to only MDL, so obviously it will take a while to add any kind of feature, especially considering the high degree of compatibility and universality that is required (jury-rigging an alternative in html, css and js you can do yourself, I'm sure, but the challenge is finetuning it properly). Try to be a little more patient, 2,5 months is nothing, and I'm sure the datepicker element will be included in a release soon.
My workaround is adding a dressed down version of jQuery UI's datepicker with MD-styling in css. It took me about 5 minutes to style, 1 minute to configure and download, and another 10 minutes to tweak to my requirements. You've spent more time complaining about the wait than you'd need to grab your own datepicker. The color codes and stuff you can find on the MD(L) website. Easy-peasy. Good luck =)
@mengsel
I am respectful for MDL, really, But you keep in mind devs get money for their job. As far I know MDL is Google product, not private and shared.
" you (don't forget) get to use for free" - not so free. Don't forget we are more Google products than users. We pay with our privacy, with using Google tools and promoting them etc, I could give many examples where my sold privacy for that "FREE" tools paid for this MDL. I alwasy place mark in checkbox to give feedback, statistics, opinions, localization, satisfaction etc. This is what Google wants from us as a payment for that free stuff. And Google gets it, I do not hide this data from Google, it's why I am not afraid to require quality and features from Google.
Thank you all for responses, I will do as you suggest, use some temporal sollution. I hope this discussion will push a little further mdl-datepicker coding.
The MDL team is limited resources and we have many different focuses. Each person thinks the thing they need is the most important. We do our best to prioritize what we feel is providing the most benefit at any given time to the most people. This is regardless of +1's or other forms of "support" given via issue comments since that isn't a good relay of true return on investment.
While 5 months seems like a long time for a component, the project is open source. If anyone wants to contribute this component, they are more than welcome to. Just understand, every PR is undergoing a few eyeballs to scrutinize them. With form elements, I'm specifically looking heavily at a11y within new modifications and additions to make sure we are providing a good foundation. Further, with new components we need to get things signed off by the MD team directly. These things take time, especially for something as complex as this component.
We were going for simple and basic components for launch. That included failing a11y in some areas. Now that we are out, things are slowing down a bit in exchange for us doing more focusing on developer painpoints with what is currently provided and to make sure we refine what exists. This way we know what pitfalls and other things to look out for when creating new additions so they are even better from their launch.
Let's also not get caught up in the fact that this is under the Google banner. Google can't just throw more developers at the project. That would only hurt the company and the project more if not done with care. Remember, the project maintainers are human and few. We can't handle everything in as timely a manner as people want. We would love to be able to do so, but we simply can't do it.
@Garbee If product is not finished its version should be below 1.0.0. This is why I honeslty share my 'heart' pain here. If it would not be 1.0.0+ I would not consider to use it as beta/alpha release may have some lacking features. My very bad mistake I trusted in this.
"Each person thinks the thing they need is the most important" - and it is.
"Let's also not get caught up in the fact that this is under the Google banner" - what? If it is branded with Google so I expect Google quality. It Google brand here is just fiction please remove it.
"project maintainers are human and few" - so obvious, ofcourse are human. Whom I should expect, reptilions? And if it is not enough I still think there should be more.
"Google can't just throw more developers at the project. That would only hurt the company and the project more if not done with care" - just above I shown you your words where you say there is not enough people, so google SHOULD throw more developers at the project or change current for better.
"project is open source" - however its Google product, so do not expect strangers will work for free for Google, while Google gets paid from us heavily.
If product is not finished its version should be below 1.0.0.
If we waited for everything to be "complete" in everyone's viewpoint nothing would ever get done or released. What we provide is good enough for simple sites and even slightly more complex sites to be built and be reliable. I myself was unhappy with everything we launched with, but we are closing in on the big holes I was worried about and learning for 2.x as we go.
just above I shown you your words where you say there is not enough people, so google SHOULD throw more developers at the project or change current for better.
Software development management is pretty complicated. Yes, a few more devs on hand may not hurt majorly. However, business decisions need to be made as far as who gets assigned where. Further, simply throwing more people at a problem doesn't mean some amazing bandwidth opens and more stuff gets done at high-quality. In the end, a handful of people who really care for something working on it with a community is better than a hundred developers tossed into something by a company just for a paycheck.
"project is open source" - however its Google product, so do not expect strangers will work for free for Google, while Google gets paid from us heavily.
It is a symbiotic relationship in this regard. If you think it is "free work" you are simply looking at one or two angles and ignoring others. One very good angle is, contributing to this project shows that you can produce quality code. Further, it helps you market yourself as a better developer to potential clients and employers. Yes, you may not see any direct monetary value returned from contribution, but what other avenues exist for contributing are numerous.
Also, in my opinion:
"project maintainers are human and few" - so obvious, ofcourse are human. Whom I should expect, reptilions? And if it is not enough I still think there should be more.
This is only shows you aren't taking the discussion seriously. The people working on open source projects are not drones that can be disregarded and demanded free code from. Making snide remarks like this is highly disrespectful. Not only to contributors to this project but also every other open source project.
@mibcadet: It is really bad to read that not everybody understands Open Source! If you miss things then add it and don't discuss! :-1:
@Garbee: I'm totally with you :+1:
@Garbee I take it very seriously, I would not share time for this talk otherwise. And I never said there should be hundred developers but 2-3 more could help you much. "If we waited for everything to be "complete" in everyone's viewpoint nothing would ever get done" - still you could mark it as like beta product not a full product.
@pierrejochem I wrote quite much open code for people, while Google use MDL as form of promotion of Google. This is quite commercial move and I do not consider contributing (as @Garbee said ) "something as complex as this component".
And above all: I am really glad of this project, thank to all people who works on it. I am only frustrated because of provided false information like 1.0.0 version or no ETA for featured modules. This false information did lead me to use it because I trusted Google brand. And got disappointed very much.
I am only frustrated because of provided false information like 1.0.0 version or no ETA for featured modules.
The only ETAs provided are the ones we assign milestones for. Because those are the ones we are actively working on. Further, the V1.0.0 is not a lie or "false information." Simply because you have a different viewpoint on what should be considered 1.0.0 doesn't mean you have something you weren't promised.
@mibcadet here for you http://codepen.io/dbellotti/pen/ZYgwYW
Hey folks,
I'm afraid this discussion has strayed too far from the topic, and would likely be very confusing and not very helpful to someone looking for date and time pickers in MDL.
I'm closing this issue and opening a new one to track development of the feature.
@sgomes Which ticket is the new one?
Not sure if this helps, but https://github.com/PuranjayJain/md-date-time-picker is neat implementation as far as I can see. I'd love this merged to mdl though!
@aymer, thanks for share. But seems it does not work with IE11.
Any time frame on when this component will be included?
Currently it is the only thing that is holding back a project I am working on from using MDL.
It won't be included in MDL 1.x. Material Components for Web, the successor to MDL, will have this component included in this at some point.
A date/time picker is too complex to properly build for Material Design adherence, a11y, and just general usage. If a community member were to propose a functioning component in a PR then we could try and review it for addition. But, the core team won't be adding something this complex into 1.x ourselves.
It would be great to have standard components for date and time fields, in line with material design guidelines.
https://www.google.com/design/spec/components/pickers.html