Another way to get web dev input: one-click intent button on MDN pages

[LeaVerou]

Just recording this idea I had while looking at sign()'s MDN page:

In addition to existing large-scale web development surveys (State of …) and MDN short surveys, I wonder if a good way to get signal could be a simple button in Limited or No availability features callout that authors can press to indicate they wanted to use this feature, but couldn't due to browser support.

I'd argue this provides better data than surveys, since it's contextual, just-in-time, rather than requiring people to look back and remember, which is prone to recency bias.

Sure, it's prone to abuse, but presumably there are mitigations in place for short surveys as well.

It could even be framed around "Notify me" [when it reaches full support] so that there's an immediate benefit, or just a more vague "Interested" (similar to sentiment chips) then asks if they want to be notified.

Sure, there's a confound that some features are visited more than others but is that really a confound? Presumably popularity is also a prioritization factor. But also, one could compare the number of interest clicks to the general page visits and use the ratio instead of the raw number to control for that.

Including something similar on caniuse could also provide useful signal.

cc @atopal @foolip

[foolip]

I think this would be very useful, not only for the Interop program but more broadly. Chromium's experience with bug upvotes is a very good one, although of course it's not a perfect signal or the only signal to consider in prioritization.

A few people have been looking into this and I've brought it up in the WebDX CG. web-platform-dx/developer-signals#7 is a building block, creating a repository with an open issue per feature, which we could use for the 👍 reactions.

A one-click button would be a great UX, but I'm not sure yet what would be required to implement that. I believe it can be done with a GitHub App that has permission to react on the user's behalf. But I'm not sure if there would have to be one app for each website (MDN/caniuse/etc) that has a one-click intent button, and whether the user would need to sign in on each site.

There are also some benefits to sending people to a GitHub repository, in particular there could be more context and explanation in the issues and repo README.

[LeaVerou]

I think this would be very useful, not only for the Interop program but more broadly.

Glad you like the overall idea! Wasn't sure what was the best repo to post the idea in, so I chose Interop since while it would benefit everyone, it provides the most immediate benefit to the Interop project.

A one-click button would be a great UX, but I'm not sure yet what would be required to implement that. I believe it can be done with a GitHub App that has permission to react on the user's behalf.

I do think the 1-click interaction is essential for this to work well. Having to go to a separate website to upvote may sound like a tiny extra step, but it will cause a big drop in engagement. From the user's point of view, even understanding what this is and what to do becomes much steeper, especially for novices. And novices are exactly the demographic that this provides a unique opportunity to capture — these people do not follow newsletters, influencers, or web development surveys but everyone looks up docs. These types of web developers would currently fly entirely under the radar (except for MDN short surveys, can't remember if those are inline or send you to a separate website).

Note

It's the O(N) user interactions we want to streamline, not the O(1) ones. Some upfront cost (e.g. login/register) is okay, but we should really try to make the voting experience as frictionless as possible. If you have to go to a GitHub issue to upvote the main additional cost isn't the extra click (that's manageable), it's the huge context switch. Even when it's within the same website, context switching is very expensive, so you usually want to minimize UI shifts (e.g. why the Web shifted from separate pages to dialogs to inline UI). The context shift of a navigation to a different website is orders of magnitude worse.

Thankfully, yes, it can absolutely be done with a GitHub app. Though implementing it as upvotes on issues has several cons:

• It restricts what data we can store quite a lot.
• We lose the ability to analyze data separately per website — all upvotes are lumped together, including those given directly on the GitHub repo.

Additionally, once you factor in all the peripheral work needed, it's unclear whether this is actually even easier:

• Creating one issue per feature just-in-time (presumably we don't want to pre-create them).
• Using our own bot to create these issues, from our own server (see how giscus works). Otherwise they are owned by random people that just happened to be first.
• Having to record the feature-to-issue mapping somewhere (or using the feature id in the title and then retrieving via the API, though that doubles the API calls)
• Processing GitHub API data into an actual dataset that we can analyze is also some work

OTOH, it does have some benefits:

• Existing API to query makes it easier to show inline UI for whether you've already voted and allow you to remove your vote
• Issue allows for additional longform discussion
• No user data stored on our end means no GDPR concerns to worry about

But I'm not sure if there would have to be one app for each website (MDN/caniuse/etc) that has a one-click intent button, and whether the user would need to sign in on each site.

If adding caniuse to the mix complicates things, let's just focus on MDN, which I think would provide the biggest ROI.

Not sure if you're asking about UX or implementation. Implementation-wise, it can be the same app, GitHub doesn't restrict by domain (you need to jump through some hoops to make OAuth work cross-domain since there's only one callback URL per app, but nothing too hard).

UX-wise, I think it's more surprising for users to have to log in to a separate service when they are on a website that already provides user accounts (like MDN), whereas having to reuse logins across websites is less of an expectation (and even when reusing the same GitHub app, they'd need to log in again, they just won't need to authorize again).

Additionally, I think it's very important to be able to analyze this data separately depending on website. I suspect MDN users are different than caniuse users or web-features-explorer users in some very fundamental ways.

Suggested Requirements

IMO, I'd say the absolute minimum requirements would be:

• In-page one click voting
• Prevent spam

Requirements that worst case could be done away with:

• Architecture that can be generalized beyond MDN (e.g. caniuse, web features explorer etc)
• Analyze votes separately by website they were on
• The page should remember that you have voted and allow you to remove your vote

And nice-to-haves:

• Ability to correlate votes by user
• Ability to store more than just upvotes

Would love to hear your thoughts!

Other implementation ideas

Beyond GitHub issues, I can think of a few other ways to implement this, depending on what tradeoff of data quantity vs quality we want to make, and how much work we're willing to put into it.

Though in the course of writing this, I think I convinced myself for the GH approach 😅

Option 1: No login at all

One option is to not use user accounts at all, just (non user-facing) spam detection and localStorage to prevent multiple votes. Then any form handling service works fine, including Formspree, Netlify forms, or even an ad hoc Netlify function which could also write the data back to GitHub periodically.
Removing a vote would basically send a second -1 vote, since this data model is basically append-only.

Pros:

• Most frictionless UX possible
• Easy to implement

Cons:

• Much more prone to abuse (e.g. get your pet features more votes) — but with the larger volumes perhaps those effects are drowned out. Also, if someone is willing to go through such lengths to get a feature implemented, that also tells us something.
• No way to correlate votes across an account (except perhaps crudely via IP or generating a UID that we store locally)
• No way for users to track their own votes, could end up voting multiple times for the same thing by accident

Option 2: Integrate with MDN accounts

MDN already supports user accounts. I don't imagine they're used very much (currently the main benefit seems to be removing ads), but once there are more user-facing benefits to having one, they may be. E.g. I wasn't logged in, because there was no reason for me to be logged in, not because I was opposed to creating an account.

For MDN, I think this is probably the option provides the best UX, but could end up being untenable. E.g. I'm not sure what infrastructure MDN is using for their user accounts and whether something like this could piggyback on it.
Ideally, this is stored in MDN's database and is tied to the user's user id.

Pros:

• Voting experience is still frictionless, all additional UX cost is O(1)
• Can correlate votes across a single account
• Can provide additional user-facing incentives, e.g. notifications (possibly not MVP)
• No (new) GDPR issues since it uses existing account infrastructure

Cons:

• Does not generalize beyond MDN
• More unknowns: Might end up being too hard to integrate with existing MDN account infrastructure
• Need to figure out how to export the data out of MDN periodically. This could end up having too many moving parts.

Option 3: Loose MDN integration + data stored elsewhere

If it turns out that integrating with MDN's infrastructure properly is too hard, there is the poor man's version: use a regular form like Option 1, with the user's user id as a hidden field, and whose UI goes through MDN login first. That would be trivial to integrate (template/UI changes only).

Pros:

• From the user's pov, the voting experience is as smooth as Option 2
• Can still correlate votes for a single account (possibly with a bit more noise than Option 2, see below)
• Could generalize beyond MDN, if we also store the account provider (e.g. mdn) in the data

Cons:

• Technically allows spoofing, where people can vote on features using someone else's MDN user id. But given that this data is only meaningful in aggregate, I don't think it would be enough to bias the dataset.
• Same append-only issues as Option 1
• GDPR concerns since we're storing user identifiers elsewhere

Option 4: GitHub auth + separate database

We don't actually need to store the data on GitHub to use it for authentication.

Pros:

• Opens up various options for better integration with Github
• Can use the same GitHub app across sites and see all your upvotes

Cons:

• Clumsy UX to have to log in to a different service when you can already have an MDN account.
• Certain demographics may not even have a GitHub account, for a variety of reasons (being opposed to the company, being too novice, etc)
• GDPR concerns since we're storing user identifiers elsewhere

---

If Option 2 is not workable (or desirable), I think the downsides of the GitHub approach are mostly manageable but I really hope we can find some way to do this separately per website. 💡 Perhaps we can create different comments within each feature thread, one for each website!