Accessibility, and the Need for Ingenious Simplicity in Computer Scripts, Languages and Programs

I’m very keen on accessibility in computer systems. Nowadays we tend to take a rather superior attitude to this problem, often assuming that the general public need only have an easy way of buying things. My old boss always felt that the only really important part of any web-based application was what he referred to as the “F…ing big ‘Buy’ button”. The old idea of using the power of a computer by typing in commands seems rather ‘retro’, even when it can save hours of tiresome ‘click upon click’ in a GUI.

We increasingly prefer to exclude people from directly interacting with the computer and have thereby created a division between the computer-savvy and the cultural proletariat. This allows us to regard accessibility as being less important, because we have the big buy button for the great majority. In the past forty years, we have discarded many of the carefully created standards that were designed to ensure that applications, whether GUI or command-line, were accessible and usable by people from a range of cultures, backgrounds and specialised expertise. The idea of applications, even GUIs, which could be linked together to manage whole extended processes has become lost, because it has been made unnecessarily difficult and geeky. What is wrong with making computer languages and computer usage more accessible?

Why should computer scripting, languages, and Command-line applications be accessible?

In those far-off days when the first personal computers appeared, and we needed a task done, there was little choice other than using a computer language, and we couldn’t get it done for us because there weren’t many professional programmers. In any case, the engineers, scientists, statisticians, psychologists and academics who needed to use the first affordable computers could not afford to employ them; and even if they could, the programmers would take a long time to get up to speed with the analysis and requirements of the application.

In the computer industry and science before the personal computer, the people who designed computer languages stressed over making them accessible to non-technical people. The first computer languages were designed for ordinary mortals. Cobol, for example, was written so it could be used by the military with minimal training. Forth, another simple language, was developed to allow astronomers to calculate to compute ephemerides, satellite station positions and orbital elements.

There was a belief at the time that computing power should be accessible to domain experts to exploit it for their specific needs, without the intermediary of professional programmers

The amazing breadth of data analysis tools that are available, and the range of statistical analyses that are now available show how successful that policy has been at university level for some sciences, but I don’t see it helping other professional groups so readily. Move away from the mathematically-inclined and computer usage becomes more like wielding a magic wand than a set of tools. This is inherently bad because any researcher (be it a scientific one, or even someone researching sales at a company), needs to be in control of the process to understand the steps and detect flaws. If you leave it to a commercial application, or someone else’s process, you lose control and supervision.

What needs to change?

There are probably three types of interface that concern us.

The first is the command-line interface (CLI), and the associated scripting ‘glue’ that make scripted processes possible. Without a doubt, both must be accessible.

I’ll give a simple example of what I would term a deliberately hostile CLI tool that offends all accessibility principles documented since the 1950s – command-line parameters that are case-sensitive, especially so where they are in Camel-case.

You might shrug and say that command-line tools all have a ‘Help’ feature. Cool except they don’t all accept the same help parameter. /h, \help, -h, –Help and all combinations but they are merciless in insisting on just the one format. Some ‘help’ parameters are even case sensitive. It is not hard to detect the hidden message here.

The Second is the computer language. Computer languages in the seventies were designed to be easy to learn, and intuitive to use. They had to be, because there was no standard visual interface until the mid-eighties. It takes time and effort to design something simple. It is extraordinarily easy to create a complicated language, and it will look impressive, especially to the programmer’s devoted relatives.

The people using the language will believe they are working hard and doing elaborate pioneering work. Unfortunately, the results could well be slower to arrive and do less.

The third is the computer application. Nowadays we can find applications for almost anything, and if we can’t find one, we can always ask Alexa to find one for us. Because people are required to work with applications in the workplace, companies are legally liable if a worker suffers from the consequences of having to use a poorly designed interface.

This is why user interfaces are specified by international standards such as:

• ISO 9241 Series – Ergonomic requirements for office work with visual display terminals (VDTs)
• ISO 30071-1:2019 – Development of User Interface Accessiblity
• WCAG 2.1 (2018) – Web Content Accessibility Guidelines
• EN 301 549 (V3.2.1, 2021) – the harmonized European Standard for ICT (Information and Communication Technology) Accessibility
• BS 8878:2010 – British Standard Web Accesibility Code of Practice

These cover issues such as accessibility, stress, cultural concerns, language and so on. Following them saves you a lot of effort and research as a IT professional, because otherwise the task of creating an application that meets these requirements is daunting. I’ve developed applications that, as well as meeting the customer’s requirements, had even to be approved by trade unions, and rightly so.

Curiously, few commercial applications conform with these standards. The important requirements have disappeared by stealth as new generations have updated applications.

Computer Languages should be usable as widely as possible.

In the seventies, I was one of those who needed a computer for the complex factor analysis models I was using as a clinical psychologist. While doing some evening work on the computer, my aging father, gazing over my shoulder, caught the computer bug.

He was a retired mechanical engineer. He borrowed the BASIC manual and before long he’s created a computer game that involved a sheepdog rounding up sheep. His first attempts were slightly wrong and the sheep chased the sheepdog which, terrified, rushed off-screen. Nothing daunted, he turned it into a bullfighting game where a maddened bull chased a matador who had to dodge out of the way.

With his technical engineering background, he got the dynamics, and the effect of momentum in the charging bull just right. No need for the moment of “It’s a UNIX system! I know this!” (the ‘Jurassic Park’ scene with the Silicon Graphics 3D File System Navigator). The Basic interpreter was easy to understand. It didn’t need a professional programmer.A computer language doesn’t have to be intrinsically clever, just reliable and usable. I was, later in life, able to use Basic (Visual Basic) to design, and help to implement, one of the earliest telephone banking systems in the UK.

The designers of these languages, including Pascal and the much-maligned Fortran, actively aimed to design languages that were simple to understand. Probably the best, and most misunderstood, of these languages was SQL. It was the first declarative language

Before SQL, most programming was procedural or imperative, in languages such as Fortran, COBOL. This is natural, because assembly language was by nature procedural. SQL marked a shift by focusing on describing the desired result rather than the process used to get there. This set the stage for the development and popularity of other declarative languages and paradigms and set the precedent for functional programming and logic programming (e.g., Prolog).The simple message is that it simply isn’t clever to introduce complexity in human-computer interaction. The real skill is to make it simple to do complex things. For me, the interest of SQL as a declarative language is that it forces the user to be clear and precise about what has to be achieved, to define the outcome rather than the journey.

In a declarative language, the clearer your code the better. You focus on the requirement and forget the pleasure that comes from creating elegance and artistry in the actual program you write, which is likely to be like burying sculptures underground. Besides, it is probably unmaintainable because it is difficult to change an elegant script.

Drifting away from simple

These points are obvious, of course, but why do languages all drift towards complexity? There are plenty of good reasons of course.

Some languages are designed to be simple but are adopted for different purposes. They then have to accommodate different programming paradigms or cater to more diverse developer needs. JavaScript, for example, started as a simple browser-based scripting language that suited web designers. It has evolved into a general-purpose language to include complex features like modules, classes, promises.

Another reason for complexity is that languages ‘age’. As languages evolve, they must ensure that existing codebases continue to work. The easiest option is to add layers of abstraction or introduce new fancy constructs that must coexist with older, simpler ones. It also leads to ‘syntactic baggage’ where there are several ways to accomplish the same thing.

They also have to accommodate changes in the computer industry, growing popularity of use , and with changing and evolving user-requirements, leading to advanced features, patterns, and constructs. There is often commercial pressure to add new libraries, APIs, or syntactic sugar to make the language more expressive or versatile, meaning more complexity.

Can languages stay relevant while remaining true to their creators’ design ideals of simplicity? Has Python, for example, stayed true to “The Zen of Python”? I think so because the designers insist on it: The basic concepts of Python can be picked up quickly, there is only one way of performing a task, and complexity is tucked away into the standard library. All extensions are carefully considered and must align with the principles of the language.

Why should Command-Line applications be accessible?

Command-line interfaces (CLI) have no international standard that prescribes how they should be designed, particularly regarding syntax, parameters, and options. There isn’t even a recognised format for input streams other than text, and output streams are likewise fraught with difficulties. CLIs are highly unpredictable in their usage, and can be highly perplexing to anyone outside your closed cultural circle, based on diverse user bases, operating systems, and software ecosystems.

However, that doesn’t mean there are no standards, but several conflicting standards based on the tribalism of the user-base. There are even strange communities of users who believe, in direct contradiction to the world outside, that ‘Load’ has a different meaning to ‘load’ or even that the commands ‘Load’ or ‘Help’ are meaningless and should be rejected by their applications.

There are several standards that cover part, but not all, of the problem. The POSIX (Portable Operating System Interface), a family of standards specified by the IEEE, defines some guidelines for CLI behaviour in Unix-like operating systems. POSIX specifies the basic command syntax, such as the use of a single dash (-) for single-character options and a double dash (–) for multi-character, descriptive options (e.g., -h vs. –help).Unfortunately, it does not cover the important issues such as a standard parameter format for the common requirements of a CLI such as help messages, verbosity, input/output redirection, or input/output formats. The GNU Coding Standards state that every program should support the convention of ‘ –help’ and ‘—version’

Conclusions

Despite all the work of the science of Human-Computer interaction, we are currently forced into accepting user interface standards that are adopted by the applications that we need to use. Sometimes these ignore the large body of knowledge on what makes interfaces are intuitive and provide a positive experience, and that makes interfaces usable for people with a wide range of abilities and disabilities. The ‘Metro’ standard comes to mind; a classic example of what can happen when you forget to balance innovation with a solid understanding of user experience principles. It’s a reminder that no matter the scale, it is important to ground your design decisions in thorough usability testing and genuine, unforced, user feedback.

When designing applications that are intended for wide-scale usage, CLI-based, or GUI based, we must submit them for usability testing. In the past, I’ve had to watch users destroy the credibility of my beautiful GUIs by merely being guided to the workstation and obliged to learn to use it without instructions. Some of my CLI apps have failed usability testing in embarrassing ways- why? The creator is too close to the work, and developers cannot easily see beyond their cultural milieu.

All developers and testers must be familiar with Ergonomics and Human Factors: and look beyond their own experience to study how users prefer to interact with computer systems, and use this information to organize and structure both content and functionality to optimize user understanding and flow.

Most importantly, we need to spend time as developers in understanding how the full range of users and potential users think and process information. By ‘full’, I include different cultures, heritage and skills, so we can design interfaces that are widely usable without compromising any of their power or specialised usability.

The post Accessibility, and the Need for Ingenious Simplicity in Computer Scripts, Languages and Programs appeared first on Simple Talk.

Source: View source