Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full-featured browsers based on WebView #41

Open
muodov opened this issue Sep 23, 2022 · 2 comments
Open

Full-featured browsers based on WebView #41

muodov opened this issue Sep 23, 2022 · 2 comments

Comments

@muodov
Copy link
Contributor

muodov commented Sep 23, 2022

This discussion was split from #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 (#40) to serve the users, and should be able to open any web page (#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. #36 (comment)). Conversely, "browsers" may provide features beyond the traditional web browsing.

I think this topic is worth exploring:

@muodov
Copy link
Contributor Author

muodov commented Sep 23, 2022

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
Copy link

pmeenan commented Sep 24, 2022

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):

  • Display 1st-party content from same-origin URLs directly inline with the rest of the app experience, using hosted HTML for parts of the application UI
  • Display specific 3rd-party content directly inline with the rest of the app experience (video playback sometimes as well as ads?)
  • Display arbitrary 3rd-party content in a view dedicated for consuming that content in its original form with some level of app integration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants