Confirmed users
228
edits
(→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'''. |