WebDev intro course: what small changes towards progressive enhancement?
9 points by k749gtnc9l3w
9 points by k749gtnc9l3w
For $REASONS, I ended up in control (probably temporarily) of a rather introductory «Web Development» course with a bit of HTML/CSS/JS/Docker that I plan (and promised) to keep in a mostly recognisable shape.
I do want to add more reminders that progressive enhancement is good, though; and I ask for advice on good points/references.
I am going to keep NodeJS backend assumption, so any JavaScript-the-language feature can be demonstrated on backend. So just learning to use JS in general is not as much of an excuse for silly things in-browser.
My plan includes telling more than before about (and probably giving links to):
And I guess general stressing that document, form, and application are three different things.
I would be grateful for suggestions of other/same-but-well-made points towards progressive enhancement, not spending extra effort to break accessibility, etc. Ideally I hope to cover what has normally been covered previously, but with a viewpoint shift towards healthy approaches. Active improvements to accessibility are probably beyond what would fit and beyond what I can explain well.
I've read a lot of articles on the "why" of progressive enhancement but few on the "how." More resources with practical examples (like your first link) can be helpful.
I think in our course volume «if you do an expensive DB request anyway, offer the data both as JSON and in HTML via a template» might be as far as will fit on «how», and also this seems to be the step that usually separates «somewhat usable» from «nothing»… but if I think of/find anew an article with a good example description, indeed a good idea to mention it.
I believe Chrome dev tools (maybe firefox too?) have a feature where you can throttle the CPU and make network requests slower (and maybe fail sometimes?).
asking students to browse the web with these constraints might be a neat way to demonstrate the benefits of progressive enhancement.
Firefox mobile device emulation easily permits to increase latency and decrease bandwidth, CPU throttling is not on the surface of that UI at least. So, overusing JS is not demonstrated as clearly… Chromium does seem to allow CPU throttling. Maybe could try that, thanks…
If it's a hands on course it could be useful to have a handful of "limited devices" that people could use to test out their websites. For example a 10-15 year old phone, a laptop running windows XP and IE6, and whatever else you can scrounge.
That could be nice, but managing handout devices would be a mess, and quickly procuring them even more impractical in our (French university) setting.
IE6 is maybe too much anyway; I am currently negotiating with colleagues reponsible for exercise sessions whether we push one of the tasks basically towards testability in w3m, and if we agree on that, we do have w3m installed around here…
For historical purposes, showing a bit of JQuery might be interesting, since it's from times when not every site was a SPA and it was so widely used.
And for the very interested people, a mention of HTMX or Alpine might be cool :)
True, I am thinking about showing JQuery exactly from «this doesn't even need frontend JS except for XYZ» point of view.