search

WebView-CG / usage-and-challenges

Documenting usage scenarios for WebView and the challenges they create
https://webview-cg.github.io/usage-and-challenges/
Other
12 stars 4 forks source link

Full-featured browsers based on WebView #41

Open muodov opened 1 year ago

muodov commented 1 year ago

This discussion was split from https://github.com/WebView-CG/usage-and-challenges/issues/36

When discussing WebView features, the use-case of "full-featured browsers" such as DuckDuckGo, keeps popping up as a special case.

Compared to (for example) hybrid apps, WebView-based browsers, such as DuckDuckGo, require more powerful WebView functionality (https://github.com/WebView-CG/usage-and-challenges/issues/40) to serve the users, and should be able to open any web page (https://github.com/WebView-CG/usage-and-challenges/issues/42) and serve as a user-preferred browsing method when possible. At the same time, users could use more built-in protection from malicious "non-browser" apps.

While hybrid apps and EPUB viewers clearly differ from browsers, the distinction may get blurry as we compare "full-featured browsers" to other WebView-based apps that embed remote web content such as miniapps (e.g. https://github.com/WebView-CG/usage-and-challenges/issues/36#issuecomment-1224250211). Conversely, "browsers" may provide features beyond the traditional web browsing.

I think this topic is worth exploring:

muodov commented 1 year ago

If I were to list the differences of browser apps, I'd consider that a browser's "main purpose" is to open web links (as suggested in https://infrequently.org/2021/07/hobsons-browser/#starting-points) and serve as a user agent in managing and protecting the browsing experience.

Assuming that user agency is the main goal, fundamentally a browser is something the user trusts. As in, they give the app an explicit permission to fully control their browsing process. Perhaps we could use this as a criterion?

pmeenan commented 1 year ago

I still don't think there's a useful distinction between "browsers" and "apps intended to show 3rd-party content in its native form with some level of application integration".

Take something like Pinterest. At a high-level, the product's purpose is to allow for a curated visual collection of web content by users and to allow for the sharing of that web content. Its "main purposes" are to open those web links, make it easy to group new web links and share those web links for other users to explore.

Is that a web "browser" that just happens to provide visual bookmark and sharing?

It is 100% operating as the user's agent - letting the user collect and share the web content where the user wants to, making it as easy as possible and attempting to protect the users from scams, mis-information or anything else that may propagate through the sharing part of the network.

To provide the best possible experience to the user, it needs a lot of the same capabilities and features as the system's default browser so that the content can be rendered accurately but it also needs to integrate in a way that makes it easy to discover new content, add that newly-discovered content to the user's own collections, etc. Some of those may collide with cross-app privacy concerns (in both directions) but there is also user friction with cross-app walls and that is the main point of difficulty in balancing, both serving the user's interest.

If Chrome adds a feature that lets you share bookmark collections with other people (and maybe provides thumbnail previews), does that make Chrome no longer a web browser?

Functionally, I still think the best lines for understanding webview integrations are around how they are integrated with the app, the type of content they plan to display and the level of app integration required for that content (which is captured in the other break-out issues):