WebAPI/DesignGuidelines: Difference between revisions

* keep your scope narrow

* discuss motivation and design sketches early, often, and widely (e.g. [[IRC]], applicable W3C/WHATWG lists, [https://lists.mozilla.org/listinfo/dev-webapi dev-webapi], [https://lists.mozilla.org/listinfo/dev-platform dev-platform], [https://lists.mozilla.org/listinfo/dev-gaia dev-gaia], blogs, Twitter, GitHub issues, etc.)

* avoid scope creep by avoiding trying to fix unrelated problems

* iterate and only expand your scope as new features are needed

* start with '''use cases and requirements'''

* collect currently shipping, available for use '''examples from other platforms''' (ex. Android, iOS)

* determine and document how the existence of these technologies impact markets (ex. lots of uses in the Google Play store)

* find articles, blog post comments, Stack Overflow entries showing that people want this feature on the web

* if possible, document how web developers are working around the missing functionality with polyfills and other mechanisms and the drawbacks of this approach ([http://usecases.responsiveimages.org/#limitations-of-current-techniques|responsive images example of this])

* use the above to '''document a need for the API beyond "it would be cool"'''

* document that existing web technologies are not sufficient and that users and developers are being negatively affected by the lack of this feature on the web

* show that there is enough consensus making this a good candidate for standardization (the <picture> element did this)

** find developers that would make use of this

** if you can't find any interested parties then this may not be the right time to standardize your API

* document potential abuse cases and attack vectors

** you don't have to know how to address the concerns, just document them

** ask someone to help you find them

** example:  http://w3c-webmob.github.io/wake-lock-use-cases/#potential-for-abuse

** http://w3c-webmob.github.io/wake-lock-use-cases

** http://w3c-webmob.github.io/netinfo-usecases/

* '''expect your uses cases and requirements to evolve''' as you attempt to standardize

* build consensus

** find interested parties who say they'll use this functionality; '''expressions of interest are critical'''

** find allies at browser vendors

** http://specifiction.org/

** https://openwebapps.uservoice.com