Amend progressive enhancement general rule

[squidsoup]

While progressive enhancement is possible in an isomorphic react app, this is technically impossible for us given that we are unable to use node serverside. Even without the node restriction, universal react apps are significantly more complex, for potentially little gain. I don't think this rule is pertinent now.

[barrymcgee]

I do not think this should be removed, but it should be amended with the caveat you outline above, i.e. - while the core functionality of certain Javascript-driven product apps is difficult to replicate without server-side rendering, we aspire to develop using the principles of progressive enhancement wherever possible.

Also, even where the above is true - <noscript> etc should be utilised to ensure no user gets a white, blank page because JS execution has failed.

Afterall, our biggest site (ubuntu.com) and the majority, if not all, of our marketing sites are initially rendered server-side where this principle should continue to absolutely apply.

[squidsoup]

Yep quite right Barry, I’ll update the copy, such that it only applies to SPAs. On Tue, 3 Jul 2018 at 2:07 AM, Barry McGee notifications@github.com wrote:

I do not think this should be removed, but it should be amended with the caveat you outline above, i.e. - while the core functionality of certain Javascript-driven product apps is difficult to replicate without server-side rendering, we aspire to develop using the principles of progressive enhancement wherever possible.

Also, even where the above is true -

Afterall, our biggest site (ubuntu.com) and the majority, if not all, of our marketing sites are initially rendered server-side where this principle should continue to absolutely apply.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/canonical-webteam/practices/pull/70#issuecomment-401817148, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH87iFRl6s3Ja_mzVmWf4hF-LW4aLh_ks5uCikogaJpZM4U-dmw .

[nottrobin]

The core content not being available on SPA apps has significant downsides which mustn't be overlooked - in tutorials.ubuntu.com (polymer) Google wasn't indexing even basic tutorial titles, which @WillMoggridge managed to solve by rendering some content server-side, but until it was fixed it was a huge problem for Marketing.

I don't think we should include wording that goes anywhere near suggesting that SPAs get a free pass on the progressive enhancement rule. My preference would be to leave this section exactly how it was, and just be acutely aware that some React apps are breaking the rule.

[squidsoup]

I think the important distinction to be made here is between public facing, content based websites, and applications where the execution environment happens to be the browser.

MAAS is a good example of the later, and provides an SPA without progressive enhancement. This category of application is:

1. Authenticated/private
2. Not constrained by low powered clients, or high latency
3. Does not require content to be indexed by search engines

I don't think there is much to be gained by requiring progressive enhancement for the later category of application. It introduces significant complexity for little gain in that context. I totally agree however that progressive enhancement should be a requirement for websites that need to be accessible to the general public, and indexable by google.

If we do want to pursue progressive enhancement as the standard for all of our applications, regardless of context, we will need to address our position on node on the server, as technically it is not feasible to build an isomorphic react client without it.

[nottrobin]

@squidsoup Ah yes, that's a good point. Previously, these practices really only applied to websites, but I agree that now they should be applicable to interfaces for applications running away from the web.

In which case, would you be happy to rewrite your update not to mention SPAs per se, but instead to mention that the progressive enhancement practice only strictly applies to websites on the actual web, and could be relaxed where we can make certain guarantees about the audience - although it should still be carefully considered?

Although, in the case of MAAS, is it really true that it's "Not constrained by low powered clients"? If I was a network administrator I might very well want to view or edit the settings from my phone on my way to the toilet, during a meeting, or in the building's cafe. And similarly, we have no control over which browser the user is choosing to use, which indeed could even be something like Lynx, if only it were supported.

[nottrobin]

How about something like:

JavaScript should progressively enhance a page.

On all publicly accessible websites, core content and functionality should still be available without JavaScript. JavaScript applications written for a more specific audience and which won't be indexed by search engines may be more lax, but should still treat progressive enhancement as a guiding principle.

Thoughts?

[anthonydillon]

I think @nottrobin point is valid. The term SPA is one of many and maybe replaced in the future. I prefer the districting to be between public websites and private applications. We shouldn't mandate the exclusion of progressive enhancement but considered per project.

[squidsoup]

Thanks @nottrobin, I think your suggested copy reads well, and I've updated the PR.

[nottrobin]

:+1: thanks @squidsoup, looks good to me =)