Online processes and APIs are great but we have to have backups and failsafes.
The failsafe is "find ways to give everyone internet access", which I think we've already done.
Libraries, public wifi APs, cheap 4G, dirt cheap internet capable devices, etc.
Foisting support costs off to libraries is another example of the tragedy of the commons.
No idea how you think this is a tragedy of the commons situation. It is definitely better to digitize everything and serve the 0.1% (certainly not anywhere close to 10%) with additional support that helps them use the digital service, rather than having non-digital fallbacks for significantly more expense.
Internet services becomes more of a win if you're remote, not less so, espescially with things like Starlink coming online.
I lived in a very rural area for about 50% of my childhood - we had no fire department, we relied on a well for water, our town's official population was in the hundreds, etc. If we wanted to get on the internet we had to do it at around 38400 and random packets would get corrupted because the lines were old and low-quality (I wrote my own parity tool in VB6 so that I could download a file 3-4 times and produce a not-corrupted version). Despite that, if I wanted to call someone up on the phone to speak with them or send a letter, that was just as easy and effective as it was when I lived in the suburbs.
When we eventually managed to get slow DSL years later it was INCREDIBLY expensive because in rural areas if you're lucky enough to have service at all the monopolist who offers it knows they can charge as much as they want.
If you don't have a sufficiently expensive phone. In an effort to prevent easily creating cheap fake accounts (presumably -- I don't actually know), phone numbers associated with low-end android devices are routinely banned from social media platforms, online banks, and any number of other organizations.
Any references where I can read more about this?
- https://www.paypal-community.com/t5/About-Settings/Tracfone-...
- https://www.paypal-community.com/t5/About-Settings/Paypal-do...
- https://www.reddit.com/r/TracFone/comments/g42vl9/phone_numb...
- https://help.id.me/hc/en-us/articles/360017839774-Why-can-t-...
At my company everyone has gone API-crazy. There's one activity in a team I used to be on that used to require a human review of a configuration change. It's something that developers on the team do just a few times a year. Someone got the idea that this should be fully automated, because I guess it would look good on their performance review if they built a new service?
What we had at the start was a description of what you were trying to do and how you could do it, but it included a manual review of a change request. It was simple, understandable, and required very little human attention.
What we ended up with was an API for a microservice with its methods half-documented and no "big picture" description of what API calls you were supposed to make in which sequence to get the job done. API calls would fail with obscure misspelled error messages, and you'd have to guess what you did wrong in the JSON file you were submitting. And then of course it ended up not working half the time, and you'd have to open support tickets or ping the entire dev team in chat to ask why you weren't getting the results you expected when using the API. Of course the initial response tended to be, "Did you read the documentation?" And the user would have to respond, "Yes. Here is what I did after trying to decipher the so-called documentation, and here's why. Here are the results I need. I'm not getting them. How can I figure out why?" At which point two or three very annoyed developers would ask for details on exactly which API calls were made with which parameters, and they'd poke into logs and whatever, before they figured out yet another untested corner case and manually fix the database entries while saying, "Well don't do that next time."
Sure, if you've got to scale to thousands of requests a week or something, building an API with a microservice might make sense. But there's a point of diminishing returns in trying to automate absolutely everything behind APIs. Some very low QPS things really should have a human in the loop by default.
At least the web is an open standard.