WebPlat charter: Focus on user research

[LJWatson]

From the AC review:
There should be greater focus on user research. Do WebPlat specifications deliver capabilities that users want/need? What design considerations do users expect from different specifications?

[LJWatson]

I agree that making user requirements a part of each specification is a good thing. By the time a spec reaches the WebPlat WG (or any other WG) it should already be clearly defined and into production, so the right time to be thinking about user research and requirements gathering is during incubation.

Ping @cwilso @yoavweiss and @marcoscaceres for thoughts from WICG.

[edent]

For example - let me pick on the Clipboard API use cases.

There are many use cases for being able to change the default clipboard operations (cut/copy/paste). We have collected a few samples to demonstrate possible uses, although these may not all be supported by this specification.

How can you write a specification without a clear understanding of all the possible use cases?

You need to be able to say something like "As a web developer, I want to be able to directly read the clipboard of a user on my site, in order to..."

Or, "As a visitor to a website, I want to know when a website tries to access my clipboard and grant or deny permission, so that I can be secure."

Ideally, every use case should be backed up by research. Even if they're not, every part of the spec should clearly say how it addresses a use case.

[marcoscaceres]

How can you write a specification without a clear understanding of all the possible use cases?

one solves for a limited set of problems.

You need to be able to say something like "As a web developer, I want to be able to directly read the clipboard of a user on my site, in order to..."

Right. Or, "users/developers are solving problem X with hack/heavy-weight/largely-used-solution Y. We should standardize that!"

Or, "As a visitor to a website, I want to know when a website tries to access my clipboard and grant or deny permission, so that I can be secure."

Or, "As a user, I just want to copy stuff! Get the hell out of my way, stupid browser.".

Ideally, every use case should be backed up by research.

Depends on your definition of "research" - but largely, agree.

Even if they're not, every part of the spec should clearly say how it addresses a use case.

Sometimes, yes... at least, it should point to some use cases and it should be obvious how those use cases are solved.

[LJWatson]

Ping @plehegar because this is something we should be doing for all specifications IMO.

[plehegar]

Having the use cases in or near the spec seems a good thing to me as well.

[marcoscaceres]

Sometimes we use the "Examples of usage" to show how actual use cases are addressed (thus mixing both the use case and code together):

https://w3c.github.io/payment-request/#examples-of-usage

Personally, I find using examples a better approach than having a list of use cases in an appendix or in some other non-nomartive section - because showing usage actually shows how problems are solved in action.

Also, use cases have different weight. And they often evolve (or get de-scoped) during spec development as Editors' or the WG have "ah ha!" moments as to nice things they can do... or can't, like all this stuff the Payment Request spec has had to postpone:

https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3A%22Priority%3A+Postponed%22