Relaunching the documentation website

The documentation website is outdated and has been disabled. As evidenced by numerous requests for examples and questions finding their way into the issue tracker, there's demand for learning resources which currently isn't being met. To hopefully alleviate the resulting unhappiness and reduce the overall maintenance burden, Steffen and I have been discussing a potential revamp of the old docs.

If you want to take a look at the last published version of the website (to refresh your memory), I've deployed an archived snapshot:

• https://webview-docs-archive.github.io/site/

Below I'll outline a few of the topics that have been considered so far. Feel free to post here any and all suggestions related to the documentation, old and new, as well as what you'd like to see covered by an updated project website/documentation in the future.

Technology choices

In previous discussions, a few different technologies have been proposed:

• mkdocs-material, which uses MkDocs for static site generation (source: https://github.com/squidfunk/mkdocs-material)
• Docusaurus, a React.js-based static site generator that originates with Facebook (source: https://github.com/facebook/docusaurus)

The old website used MkDocs. Personally, I'm not familiar with MkDocs, so I'll have to set up a prototype in order to see what it has to offer. I'm quite familiar with Docusaurus however and this is currently my preference. It's newer, and seems to be much more popular:

• mkdocs-material: 20.3k stars, 311 contributors, 6344 commits (since Jan 2016)
• mkdocs: 19.1k stars, 243 contributors, 2113 commits (since Jan 2014)
• docusaurus: 55.6k stars, 1167 contributors, 6075 commits (since Jul 2017)

Given that the content is written in Markdown either way, the primary differentiator would be support for advanced features.

Required features

The requirements listed in this older discussion may need to be re-assessed:

• Versioning: I'm not sure how important this is when there isn't a LTS schedule. Clearly increases maintenance cost
• Translations: Is this needed at all? I don't believe it would be feasible to maintain multiple versions, nor useful for this project
• Core documentation: Unclear what exactly should be documented, but otherwise uncontroversial
• Bindings documentation: This isn't obvious to me as bindings may be experimental, abandoned, or broken (separate discussion)
• Organizational documentation: Not sure how much there is to actually document, but generally it makes sense to include

If there's other requirements that should be considered before setting up a new website, please let me know.

Update: One aspect worth researching is support for different browsers, especially older ones. So far it seems that:

• Docusaurus doesn't support IE 11 - should investigate how sites are rendered in this case
• Older mobile browsers may not always be able to render a (minimal) version of the website

I can look into testing different configurations, but we'll have to define how much backwards-compatibility is needed.

webview.dev domain

The original domain is no longer available. From webview/meta#10 (comment):

The domain name is/was well beyond the expiry date, and is now listed for sale on Namecheap at a staggering acquisition price of nearly $4,000 with a renewal price of just over $200/yr.
Although this outcome is disappointing, the domain name isn't to me worth the asking price and running cost, and therefore I'm going to accept the loss of the webview.dev domain name and move on.

I was unable to find an actual list, but based on this Hacker News thread it sounds like webview.dev might be a "premium" domain:

We price some domain names higher than others to help prevent cybersquatting, so that desirable domain names remain available for legitimate registrants rather than being sold for extravagant sums on the after-market. We have never increased the price of a single domain name after registration in our entire decade of existence.

To keep things simple and avoid having to deal with domain registration woes, webview.github.io might suffice for now?

Steffen has been looking into alternative TLDs. Whatever the final decision will be, it shouldn't affect the content of the website.

Subdomains (for language bindings)

It's been proposed here that there be subdomains for the individual bindings. This isn't possible when hosting the website with GitHub Pages, as far as I can tell. I'm also not sure how useful it would be. Creating separate pages is easy enough and has a similar effect, IMHO.

It's unclear to me what the maintenance status of the various bindings is, but that question is out of scope for this discussion. If some of them aren't actively maintained or otherwise "officially" supported by the webview authors, linking to them might not be the best idea.

Modernized CSS theme

The old website appears to use a generic "default" theme. It might be desirable to create a different one that's more recognizable.

I haven't spent any thought on this and I'm not a professional web designer, so if someone wants contribute a design, be my guest.

Development timeline

Work on the new website won't be starting before next month or so (at least I won't have the bandwidth to set anything up).

In the meantime, I hope to gather some feedback and ideally compile a list of key requirements. Then I'd start with a MVP:

• Automated deployment to GitHub Pages (via GitHub Actions workflow). same as before
• Placeholder landing page - not sure what to put here yet, suggestions are very welcome
• Link to the bindings, API docs, and anything else from the main repos that might be relevant
• There should definitely be a section for examples and a brief tutorial, though the scope is left TBD
• All of this would be in an "unofficial" fork so as to avoid presenting users with unfinished docs

Once a functional prototype exists, certain parts from the README and other sources could be revised and moved to the docs.