11

Unlocking new capabilities for the web

 3 years ago
source link: https://developers.google.com/web/updates/capabilities?amp%3Butm_medium=feed&%3Butm_campaign=updates_feed
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Unlocking new capabilities for the web

Web apps should be able to do anything native apps can. We want to make it possible for you to build and deliver apps on the open web that have never been possible before.

The web is an amazing platform, it reaches users all around the world - on essentially any device. It’s easy to use, and easy to share. There’s nothing to install. But most importantly, it’s an open-ecosystem that anyone can use or build on.

There are some apps that are not possible to build and deliver on the open web today. We call this, the app gap. The gap between what’s possible on the web and what’s possible on native. We want to close that gap. We believe web apps should be able to do anything native apps can.

Through our capabilities project, we want to make it possible for web apps to do anything native apps can, by exposing the capabilities of native platforms to the web platform, while maintaining user security, privacy, trust, and other core tenets of the web.

To see a list of all the APIs that are currently in development, check out https://web.dev/fugu-status/

How will we design & implement these new capabilities?

capabilities-process.jpg

We developed this process to make it possible to design and develop new web platform capabilities that meet the needs of developers quickly, in the open, and most importantly, work within the existing standards process. It’s no different than how we develop every other web platform feature, but it puts an emphasis on developer feedback.

Developer feedback is critical to help us ensure we’re shipping the right features, but when it comes in late in the process, it can be hard to change course. That’s why we’re starting to ask for feedback earlier. When actionable technical and use-case feedback comes in early, it’s easier to course correct or even stop development, without having shipped poorly thought out or badly implemented features. Features being developed at WICG are not set in stone, and your input can make a big difference in how they evolve.

It’s worth noting that many ideas never make it past the explainer or origin trial stage. The goal of the process is to ship the right feature. That means we need to learn and iterate quickly. Not shipping a feature because it doesn’t solve the developer need is OK. To enable this learning, we have come to employ the following process (although there is frequently some re-ordering of later steps due to feedback):

Identify the developer need

The first step is to identify and understand the developer need. What is the developer trying to accomplish? Who would use it? How are they doing it today? And what problems or frustrations are fixed by this new capability. Typically, these come in as feature request from developers, frequently through bugs filed on bugs.chromium.org.

Have a suggestion for a capability you think we should consider? Tell us about it by filing a new feature request. Please be sure to include as much detail as you can, such as the problem you're trying to solve, suggested use cases, and anything else that might be helpful.

Create an explainer

After identifying the need for a new capability, create an explainer, essentially a design doc that is meant to explain the problem, along with some sample code showing how the API might work. The explainer is a living design document that will go through heavy iteration as the new capability evolves.

Get feedback and iterate on the explainer

Once the explainer has a reasonable level of clarity, it’s time to publicize it, to solicit feedback, and iterate on the design. This is an opportunity to verify the new capability meets the needs of developers and works in a way that they expect. This is also an opportunity to gather public support and verify that there really is a need for this capability.

Move the design to a specification & iterate

Once the explainer is in a good state, the design work transitions into a formal specification, working with developers and other browser vendors to iterate and improve on the design.

Then, once the design starts to stabilize, we typically use an origin trial to experiment with the implementation. Origin trials allow you to try new features with real users, and give feedback on the implementation. This real world feedback helps shape and validate the design, ensuring we get it right, before it becomes a standard.

Ship it

Finally, once the origin trial is complete, the spec has been finalized, and all of the other launch steps have been completed, it’s time to ship it to stable.

Design for user security, privacy, and trust

Some of these features may seem scary at first, especially in light of how they’re implemented on native. But the web is inherently safer than native, opening a web page shouldn’t be scary.

Nothing should ever be granted access by default, but instead rely on a permission model that puts the user in total control, and is easily revoke-able. It needs to be crystal clear when, and how these APIs are being used. We've outlined some of our thought process in Controlling Access to Powerful Web Platform Features.

Was this page helpful?

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK