You have an idea for a new JavaScript proposal, but don't know exactly what shape it should take? This document is for you!
If you are new to research, it might be overwhelming at first. For this, there is a great intro video series to help get your feet on the ground.
Works well if we don't know the use case, but know that there is something there. This is the most future oriented approach, but it also requires very good observation and forward thinking. The expected result from this kind of a study is a set of problem statements. We use exploratory interviews when we know there is probably a problem, but we don't know the full shape. The outcome of such an investigation should be a set of users and their problems, as well as how significantly different challenges impact them. It is a good opening study. Example paper 1. Paper on what not to do (really good read) 2.
This comes to us from the field of linguistics. This is if we know the problem, but we don't know the expression of the problem. This helps prioritize which use cases should be focused on, and if a proposal should be split into two, or two proposals should be unified. For example, let's say we have a problem we want to solve -- but there are corner cases that could significantly undermine the current design. Doing a corpus analysis to see how this corner case is managed could deprioritize the corner case or necessitate the change in design. I recently used this technique to reject a proposed change to an api because I found that the cornercase had an incidence of less than 1% and would undermine the primary use case. Corpus analysis relies on existing solutions being present in the wild. It can be automated. It would work well for something like Input Element types and determining if physics animation should be prioritized. Example paper looking at languages 3. Description of approach 4
a framework for evaluating how a given notation performs for a given task, given a certain user. You need to know those before starting -- and it needs to be rather specific. For example, given a developer with 10 years of javascript development working on a dynamic site that uses date-time input, how well does the current notation fare on the CDN framework -- this is an example of the kind of question we would need. CDN is used to determine things like mental load and ease of use. There is an established survey format for this. This would work well for determining the final form of known use cases like the customizable select and Physicis animation. Example papers 5. Structured survey 6
This is a more numbers oriented approach. We have two designs, and we have determined which features we want to optimize (we can get that from CDN). Then, by using timers and correctness checks -- we can run a study to see how developers fare. Example paper 7, and example project is quorum 8.
A couple of these would probably benefit from a few research techniques. For example Observable streams in the DOM might benefit from concretely establishing users and specific problem spaces, then following up with CDN for the api design.