Single page with all operators vs. One operator per page

[feloy]

Hi, I would like to discuss about the fact that all the operators docs reside in a single page. I can see different problems with this single-page design:

• the page will contain a lot of text, images and links to jsbin to read all at once
• it won't be possible to optimize the search engine referencing for single operators

Would you be interested that I propose a new design based on one page per operator?

[btroncone]

This is something I went back and forth with when designing this section. In the long term as we fill in the documentation the page will either have to load content incrementally on scroll or we would need to switch to swapping out the operator content as you click through (as you propose). Loading 70+ images + diagrams + multiple JSBin embed's all at once just isn't feasible.

The downside is you lose discovery through simply scrolling, the user would need to click through instead. I'm not sure how important of a use-case that is though.

I say go for it and let's see how it feels in comparison. There shouldn't be much that needs to be done to convert the page. I noticed a couple of UI quirks with the scroll container in the last update, maybe you could take a quick look at that while you are in the area as well?

Thanks for your help!

[ladyleet]

@feloy @btroncone 👍

[feloy]

I've just made a PR for the container scroll bug. I'm working on a version with a single operator per page.

[btroncone]

Thanks, merged! 👍

[feloy]

@btroncone I'm working on 3 different PRs:

• separation of operators in different pages, with the use of Title and Meta services to make SEO optimization
• add universal rendering support to pre-render to HTML pages of the website
• an upgrade to Angular v5 needed to Universal with lazy loading

[ladyleet]

@feloy love to see that!