-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State of CSS 2022 ToDo #2
Comments
I think we can probably get rid of the pre-processors category. Maybe the survey should focus more on features/usage and less on libraries anyway? |
New questions:
|
Other changes:
|
Hi Sacha, A few initial thoughts while going through the features today. Houdini
Features that could be added
Features that could be removed
Other
Meta
|
Those all seem like great suggestions! I'll leave the discussions of specific properties for later, but just to address a couple points:
|
The thing is, we don't have consensus in the CSS WG about whether it's even going to be called
Not sure what I was thinking, that didn't make sense indeed. 🤣 I just edited to reword. I meant make them separate, so that A doesn't include B and vice versa.
I wasn't suggesting we remove it, just wondered if we can integrate it with the large list of questions we already ask. I can't find this question in the 2022 survey so I'm not sure if it's a freeform text field or a multiple choice question but if it's a freeform field it's often hard to think of examples (even if you were looking at them a few minutes ago in the previous pages) and if it's a list it can be tedious to go over the same list twice. There could still be a freeform field at the end asking if there are any other features they don't use due to browser differences. |
Yes it was a freeform field. The reason why I'd rather not integrate this to the feature questions like you suggested (even though that would be a great idea) is that changing the available answers would make it harder to establish a valid historical comparison with previous years. It would become hard to be sure if data is different because of trends or because of the new question wording. |
Btw I'll go through your post and update the outline accordingly next week and then we can have another round of feedback, or maybe even already open it to public comments if we feel it's good. |
Here's the freeform question from 2021: Some responses, like Scrollbar Styling, aren't things we asked about as features, but most of them were. I assume there's a priming effect, that developers are more likely to name features they've just been asked about. Nevertheless, it was useful, and motivated multiple Interop 2022 proposals. If there is a way to ask "does this feature give you trouble" for each feature without invalidating historical comparison, then that could be very valuable, at least for some features. I suspect it would not be trivial to implement, but one option could be to say "Here's a list of features you've used. Have you had difficulties using any of them (because of differences between browsers)?" Maybe as checkboxes, or maybe as a freeform text field. And then possibly an "any other features" question. Final thought. One has to be careful to not make the survey tedious with this sort of question. The type of question that would give us the most insight if answered faithfully by everyone might not be the same as keeps developers engaged. For every addition we should probably remove something else. |
One way to remove the priming effect is to ask before the long list of features. But then you have the opposite problem, of respondents not being able to remember the relevant features off the top of their head. |
I like the idea of isolating the features that we already know people use based on their answers, and then asking for more details on those specifically. This could be a good temporary solution until we change the main feature question itself (but I'd like to do some testing before we do that so I don't know if it'll be possible for this round of the survey). |
This is an alternate design I have in mind for the library evaluation questions, but the same principle could apply to features. Instead of offering 3, 4, 5, etc. choices for each item sequentially, group the choices in a series of yes/no questions where each successive step only shows the relevant items. If we do switch to this format (assuming it's faster/easier/better) I think that'd be a good time to introduce the new "does this feature give you trouble" question, because we'd be messing with the question format anyway. I guess the first step would be deciding whether switching to that format would work better or not in the first place? |
I think when you have such a long list of questions, it's very tedious to go over them twice, even if it's a reduced set. |
Hmm yeah good point. Two other possibilities:
I think 1. might be the best but the downside is that it's harder to distinguish between someone having not answered the question yet (or skipped it) and someone who just hasn't heard of any of the items. But then maybe we can have an explicit "I haven't heard about any of these items" button…? |
It's not a drastic change but I think grouping the options like that might be worth a try, and I think it's close enough to the current format that it wouldn't impact the ability to make historical comparisons too much. This is for libraries though, for features I think keeping things the same and then doing a follow-up question is probably best since the current feature question doesn't quite follow the same pattern anyway. |
Oh actually another idea (or someone might have mentioned it already [EDIT: this is exactly what @LeaVerou suggested actually!]), but we could do the follow-up inline with the question, but only if people check that they've used a feature. This way we don't modify the original question at all but are still able to collect extra data? Also if the follow-up question consists of checkboxes rather than e.g. rating a feature on a scale from 1 to 10 like in a matrix question, it makes it easier for people to just skip the follow-up if it's not relevant (for example maybe they have no issues with the feature at all, so they just move on). |
Yup, in fact that's basically what I suggested in the email thread:
Note we need to collect this info even if they have just heard of it, as these may be reasons they didn't use it in the first place. I really like the multiple options you're proposing here as opposed to just focusing on browser support, though with that many choices I'd worry about cognitive overhead, and it's hard to make the UI not jump around too much when the question is shown. |
I guess it depends on your definition of "used it"… for me that includes trying it out and then realizing it's not usable in production, for example. So I would probably vote for not showing the follow-up when people say they've just heard of a feature, as to me that means they haven't done any actual coding with that feature. I also want to avoid lengthening the survey too much, which I feel like triggering the follow up for 2 out of 3 potential answers would do. As for UI jumping that's a good point, maybe we can use transitions to smooth it out or something. |
Btw for the 2018 State of JS survey we actually had "what do you like about X" and "what do you dislike about X" questions for each of the libraries: https://2018.stateofjs.com/front-end-frameworks/react/ I don't remember how those questions were phrased but I could see reintroducing them in some form as a follow-up to the libraries questions to parallel what we're discussing for the features questions. |
Oh and we could have an "Other…" freeform field too, I think this would be a pretty awesome way of collecting really granular, qualitative data for a specific feature. I think it'd be cool to also let people know that what they type in that box has a very high chance of being read by people at Google, Apple, Firefox, etc. who can actually do something about those issues! |
Moving UI discussions to Devographics/Monorepo#99 |
I think we can probably declare as a rule that if something doesn't exist on MDN or CanIUse yet it's too new to be included in the survey (thinking of object-view-box specifically here). |
@LeaVerou does it make sense to ask about color fonts separately from font-palette? |
Absolutely. Not everyone who uses color fonts needs to customize their colors. Also color fonts existed for a lot longer than |
Closing this since we now use separate issues to track feedback. |
:is
selector?The text was updated successfully, but these errors were encountered: