As you may know, this summer I am leading the design of the inaugural State of HTML survey. Naturally, I am also exploring ways to improve both survey UX, as well as all questions.
Shaine Madala, a data scientist working on the survey design team proposed using numerical inputs instead of brackets for the income question. While I was initially against it, I decided to explore this a bit further, which changed my opinion.
You have likely participated in several Devographics surveys before, such as State of CSS, or State of JS. These surveys have become the primary source of unbiased data for the practices of front-end developers today (there is also the Web Almanac research, but because this studies what is actually used on the web, it takes a lot longer for changes in developer practices to propagate).
You may remember that last summer, Google sponsored me to be Survey Design Lead for State of CSS 2022. It went really well: we got 60% higher response rate than the year before, which gave browsers a lot of actionable data to prioritize their work. The feedback from these surveys is a prime input into the Interop project, where browsers collaborate to implement the most important features for developers interoperably.
So this summer, Google trusted me with a much bigger project, a brand new survey: State of HTML!
A while ago I posted a call for feedback to inform the design of the State of CSS 2022 survey. The response has been overwhelming and it was glorious. We got quite a lot of proposals, feedback, votes. But that also meant we had to make some tough decisions about what gets in the survey and what doesnât, otherwise weâd end up with a survey so long nobody would want to finish it!
In the end we added questions about 15 new CSS features based on proposals in that repo, and decided against adding 9. Overall, there are 30 new CSS features the 2022 survey asks about. To make space for all of that, we also removed a few that were not really shining much light into what developers do anymore, and also a couple others that were not actually about CSS.
However, CSS features are not the only â or even the most important questions being asked.
Since 2019, the annual State of CSS survey has collected feedback from web developers from across the world to try and take the pulse of the CSS ecosystem, and itâs become a valuable resource not only for CSS developers, but also for browser vendors. This summer, one of my side projects is helping out with survey design and outreach for the State of CSS survey, thanks to a generous Google UI fund grant.
The target is for the survey to launch in mid September, and we are currently working on the outline. So far we have created a preliminary outline based on last yearâs survey and early research. All our work happens is in the open, in this repo. Here are some of the changes from last yearâs survey:
color-mix()scroll-behaviorscroll-paddingfont-palette:focus-visible:has() pseudo-class:where() pseudo-classWe are currently looking for feedback from the community, including suggesting CSS features to ask about, libraries and tools, or even new questions altogether.
There are also some design issues to flesh out, youâre welcome to weigh in there too.
If you want to quickly vote on which features are most important for you to make it into the survey, you can do that either via GitHub đđźreactions, or here (which uses GitHub reactions behind the scenes). Do note that reactions are only one metric among many we will use to consider items.
The feedback period will be open until August 20, then we will start working on launching the survey.
Do note that browser makers are looking at this and similar surveys to prioritize what to implement. This is why Google is sponsoring this project. So any effort you put into survey outline feedback, and on responding to the survey when itâs ready, could come back to you tenfold when your favorite CSS features get implemented faster!
First off, some news: I agreed to be this yearâs CSS content lead for the Web Almanac! One of the first things to do is to flesh out what statistics we should study to answer the question âWhat is the state of CSS in 2020?â. You can see last yearâs chapter to get an idea of what kind of statistics could help answer that question.
Of course, my first thought was âWe should involve the community! People might have great ideas of statistics we could study!â. But what should we use to vote on ideas and make them rise to the top?
I wanted to use a repo to manage all this, since I like all the conveniences for managing issues. However, there is not much on Github for voting. You can add đ reactions, but not sort by them, and voting itself is tedious: you need to open the comment, click on the reaction, then go back to the list of issues, rinse and repeat. Ideally, I wanted something like UserVoiceâ˘ď¸, which lets you vote with one click, and sorts proposals by votes.
And then it dawned on me: Iâll just build a Mavo app on top of the repo issues, that displays them as proposals to be voted on and sorts by đ reactions, UserVoiceâ˘ď¸-style but without the UserVoiceâ˘ď¸ price tag. đ In fact, I had started such a Mavo app a couple years ago, and never finished or released it. So, I just dug it up and resurrected it from its ashes! Itâs â quite fittingly I think â called MaVoice.
You can set it to any repo via the repo URL parameter, and any label via the labels URL param (defaults to enhancement) to create a customized URL for any repo you want in seconds! For example, hereâs the URL for the css-almanac repo, which only displays issues with the label âproposed statâ: https://projects.verou.me/mavoice/?repo=leaverou/css-almanac&labels=proposed%20stat
While this did need some custom JS, unlike other Mavo apps which need none, Iâm still pretty happy I could spin up this kind of app with < 100 lines of JS :)
Yes, itâs still rough around the edges, and Iâm sure you can find many things that could be improved, but it does the job for now, and PRs are always welcome đ¤ˇđ˝ââď¸
The main caveat if you decide to use this for your own repo: Because (to my knowledge) Github API still does not provide a way to sort issues by đ reactions, or even reactions in general (in either the v3 REST API, or the GraphQL API), issues are instead requested sorted by comment count, and are sorted by đ reactions client-side, right before render. Due to API limitations, this API call can only fetch the top 100 results. This means that if you have more than 100 issues to display (i.e. more than 100 open issues with the given label), it could potentially be inaccurate, especially if you have issues with many reactions and few comments.
Another caveat is that because this is basically reactions on Github issues, there is no limit on how many issues someone can vote on. In theory, if theyâre a bad actor (or just overexcited), they can just vote on everything. But I suppose thatâs an intrinsic problem with using reactions to vote for things, having a UI for it just reveals the existing issue, it doesnât create it.
Hope you enjoy, and donât forget to vote on which CSS stats we should study!