COBOL is a programming language that was originally designed in 1959, an era that many people might think of as being “before computers”. That’s not true, of course; they just didn’t have computers at home. The language is still being used by some businesses on giant mainframe computers. It’s a bit like Linux: people interact with it every day, they just don’t know it.
The point here is simple: the world more or less runs on old code, and that’s not always a bad thing. We, as designers and front end developers, could learn a thing or two.
We generally think of older code as being slower and less secure. This actually varies greatly depending on the system in question. Hey, how many script kiddies do you know that could hack into anything running on COBOL, when they might not even know what it is? Sometimes old code is just more dependable.
All that work to get rounded corners into the spec, and we started using Metro-inspired flat design practically the next day
Now on the Front End, this is an issue of compatibility. IT departments around the world are doing a better job of updating their software, and most individuals use browsers that update themselves. Even so, there are some use cases when you can’t afford to let any potential user fall through the cracks. There will be times when certain bits of CSS3 just aren’t available to you, when you might have to go back to a float-based layout, or even—God forbid—back to XHTML. Pushing the envelope is fun, but there will be times when old code is just plain better better than a polyfill.
Hey, it’s not like we use rounded corners nearly as often as we used to, anyway. All that work to get rounded corners into the spec, and we started using Metro-inspired flat design practically the next day.
Government
Governments should ideally be using the latest, greatest, and most secure back end code, but they don’t. I mean, governments are known for being out of touch, and out of date. It’s sort of what they do. While this approach is often terrible for policy and backend code, it’s ironically kind of a boon to compatibility on the front end.
Anyone working in the government sector has a moral responsibility to make sure everything they make is backwards compatible enough for every single one of their constituents to access it. This includes people with aging family computers, even people whose only contact with the Internet happens in libraries, people who only have a smartphone, or what-have-you.
I mean, it’s government. When people cannot access the services a government provides, then government may as well not exist. In a case like this, a site that can be used on old browsers is literally a matter of public welfare.
Side Note: Internal Web Apps in Government and Publicly-funded Services
Have you ever seen a library’s online catalog that wasn’t a little ancient? Publicly-funded services like libraries wish they got the IT budgets that even stingy corporations are willing to front. Working on ten-year-old (or older) hardware is not at all uncommon. This happens in constituencies all over first world countries and the developing world alike, in small towns and big fancy states.
Don’t even get me started on federal agencies worldwide. If the department doesn’t generate massive revenue or bundles of good PR, chances are that they’ll get stiffed in the budget meetings. When it comes right down to it, politics affects UX. If you’re making something for internal use by a public service or governmental department, ask them what hardware they’re using. Ask to see their worst and oldest machines, because your website/app has to work on them.
Health Services
Whether it’s a site for a health insurance provider, a hospital’s internal management application, or just an app that helps you get to a health provider faster, backwards compatibility is an imperative. While doctors might get paid plenty, that’s not necessarily a guarantee for the IT departments, and people of every economic class get sick at some point.
It’s just that, not to put too fine a point on it, any hiccup in these systems in this context could literally kill people. It might be a rare thing, but what developer or designer wants even one death on their conscience? It puts a whole new kind of pressure on cross-browser layout testing.
Ecommerce and Other Generally Massive Sites
Thankfully, a site that doesn’t load for everyone in the wonderful world of ecommerce isn’t going to kill people… probably. All you have to lose is money. Of course, no one likes that.
Now small sites in general, and niche or luxury-focused ecommerce sites can get away with targeting a smaller number of browsers to maintain compatibility with. Any design researcher worth their salt will figure out what browsers their users prefer, and go with that.
The bigger your audience, though, the larger the number of people who use “non-standard” browsers. It’s just kind of how that goes. When the numbers get bigger like that, even if it’s only a few percentage points, it becomes less forgivable to ignore those users. This is especially true for publicly traded companies. Shareholders may not respond well to excuses like, “But who cares about Edge?”
Anywhere People Don’t Upgrade Their Hardware Often
Governments, public services, and hospitals aren’t the only places that get stuck with old hardware and software. It happens in companies all around the world. Administrators everywhere really seem to like their standardized systems, even when those systems might be a little out of date.
Companies big and small can end up feeling very afraid of change. In the big ones especially, one single day of having their systems out of commission represents a loss that, even if it would be a justified short-term sacrifice, feels too risky. Old hardware just comes with the territory.
You will, as always, have to assess each job as it comes. Some days you’ll be living in the future, and on others, well… 2009 was a simpler time. Enjoy the nostalgia.
| Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5! |  |
from Webdesigner Depot https://www.webdesignerdepot.com/2018/12/when-to-use-old-code/
No comments:
Post a Comment