Nothing could be further from the truth! Feature designers are looking for *needs* to meet and *constraints* to satisfy. Fully specifying the minute details of a broad-strokes sketch introduces designers to the wrong level of detail, drowning them in complexity.
-
-
Well-written Explainers include loads of sample code and zero WebIDL. This makes folks most-fluent in Specish uncomfortable, but it's the correct choice for all of the previously discussed reasons. IDL doesn't tell a web developer anything about the system; sample code *does*.
Show this thread -
The role of Explainers also changes over time. When incubating designs graduate to formal standards bodies, ship in multiple implementations, and earn their hard-fought place on MDN, perhaps they aren't needed. But at every moment until all those conditions are met, they help.
Show this thread -
...and they help a gradually shifting constituency. Early on, they help sell the problem as much as the solution, building developer and implementer enthusiasm at the possibility of solving the issues.
Show this thread -
Later in the process, they serve as front-matter for a formal spec. Opinions differ in various forums as to the role and necessity of example code and non-normative text within specs. Explainers provide a home for that context regardless.
Show this thread -
Lastly, the iteration and evolution of an explainer captured in source control helps to document the process by which the final deliverables came to be. This can be hugely valuable to future designers.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.