canmove, Confirmed users
901
edits
WebAPI/DesignGuidelines: Difference between revisions
→Design considerations
m (Add periods to make it screen reader-friendly) |
|||
| Line 57: | Line 57: | ||
==Design considerations== | ==Design considerations== | ||
* put users first, especially their privacy and security of their data and hardware | * put users first, especially their privacy and security of their data and hardware. | ||
* don't fight the web's security model | * don't fight the web's security model. | ||
* build on top of web standards | * build on top of web standards. | ||
** use common idioms | ** use common idioms. | ||
** don't build on top of features specific to one browser | ** don't build on top of features specific to one browser. | ||
* attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks) | * attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks). | ||
* ensure the API is "webby" | * ensure the API is "webby". | ||
** if you're coming from a Java, C, or C++ background, you may want to speak with JavaScript people | ** if you're coming from a Java, C, or C++ background, you may want to speak with JavaScript people. | ||
* researching underlying implementations of what you'll be exposing to the web may help you design something that will ease implementation for the web | * researching underlying implementations of what you'll be exposing to the web may help you design something that will ease implementation for the web. | ||
* work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives) | * work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives). | ||
* use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...) | * use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...). | ||
** But there is nothing wrong with events and such. | ** But there is nothing wrong with events and such. | ||
** Don't use new features just for the sake of being cool and hip. Use them when they make sense. | ** Don't use new features just for the sake of being cool and hip. Use them when they make sense. | ||
* the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered | * the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered. | ||
* standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors | * standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors. | ||
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers | * bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers. | ||
* web APIs are "forever" so be very careful with what you expose to the web! | * web APIs are "forever" so be very careful with what you expose to the web! | ||
* Be consistent. No special cases in the APIs. | * Be consistent. No special cases in the APIs. | ||