WebAPI/DesignGuidelines: Difference between revisions

no edit summary
(→‎Design considerations: Avoid "ask the user" as an attack mitigation mechanism when possible)
No edit summary
Line 10: Line 10:
* publicly discuss & document use-cases, motivations, and design sketches early, often, and widely (e.g. [[IRC]], wiki (here on WikiMo or http://wiki.whatwg.org/ ), 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.).
* publicly discuss & document use-cases, motivations, and design sketches early, often, and widely (e.g. [[IRC]], wiki (here on WikiMo or http://wiki.whatwg.org/ ), 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.
* avoid scope creep by avoiding trying to fix unrelated problems.
** For an example of what NOT to do, see Google's "Web Intents", which scope creeped to try solve all data-to-code-or-service binding/launching problems.
** For an example of what NOT to do, see Google's "Web Intents", which scope creeped to try to solve all data-to-code-or-service binding/launching problems.
* iterate and only expand your scope as new features are justified by documented use-cases.
* iterate and only expand your scope as new features are justified by documented use-cases.
* start with '''use cases and requirements'''.
* start with '''use cases and requirements'''.
Confirmed users
228

edits