The User Interface Hierarchy

The User Interface hierarchy is the hierarchy imposed by a developer upon its users by a combination of their developer choices and the privatization of the input/output methods.

UI and Software Development

The User Interface (UI) is the combination of input/output methods that specifically interact with end users. Most software depends on some kind of input, either from a program, another computer or an end user. This input is integral to the flow of the program, as input dictates the direction the program branches through its runtime by manipulating its environment through this interface, while output directs the future inputs of end users. While all input/output interfaces have design challenges, the UI is unique in that it has to coordinate with the needs of end users, who have far more unpredictable behavior than what is established in communication protocols or messaging systems - and ultimately, all software must reach end users to be useful to people.

UI emerges as part of the development process as a consequence of all software directly or indirectly interacting with end users. When software, such as a video game, begins as an idea in a developer’s head, it has no determined structure - a person wanting to build “a video game” has limitations on what that video game may be, but there are an infinite number of ways to implement that video game. When the developer starts building out a set of specifications to describe how to build the game, they divide the idea of the game into pieces that allow it to be transformed into code. This is where the foundations of UI form - through the process of this division, strict rules are defined based on how the game should interact with the virtual I/O components (such as controllers for a keyboard, mouse, display, speakers, ect).

These divisions then act as anchor points for the code to be transformed into a compiled executable form. This transformation forces all the divisions to assemble together, squeezing them together to produce a single complete entity that is “pressed” through a compiler into machine code. This creates another layer of UI - transplanting the UI specifications as a template to compile the code into a single executable so that it can run on actual physical hardware. In this compiled form, code exists as potential, where it has many possible branching possible executions. Finally, when an end user interacts with the code, this determines a particular workflow of the application. This completes the synthesis of UI as the user interacts with this specific workflow.

This translation from a software developers idea to an eventual end user experience is, in of itself, not necessarily hierarchical. An open source development cycle allows an end user to contribute their own changes to the source and resubmit them to the author to work collaboratively, allowing both sides to become developers and end users simultaneously, by cycling this information back to a developer, maybe even the same end user, to become a new, more refined idea as they correct bugs they experience in the code, while developing parallel with other developer and end users. However, because this exposes the source to the public and allows code to be replicated by competitors with no cost, most code is privatized in commercial settings, which forces this development to go in one direction, dispensed from the developer, and the developer only responding indirectly to end user responses.

Code Privatization and Capital

Code for commercial applications is usually distributed as a compiled executable, often with copyright protection installed, with the original files kept private, and is usually protected by proprietary licenses, which limit what a user can do with an application, including number of installations, online requirements and stipulations against reverse-engineering and piracy. In some cases, source code is still visible, but with specific limitations and requirements. The privatization of source code locks the input/output methods behind legal tape, closing off public access to documentation about most of its structural components, and forcing the hierarchy directly on all of its users.

Controlling the UI Hierarchy directly benefits capitalism by controlling the way that people interact with software flows. This is actively exploited in the form of Dark Pattern Designs. The huge advantage of exploiting Dark Patterns using a combination of UI Hierarchy with psychological techniques encourages the propogation of narrow control flows on the internet, which are pushed to further extremes by the largest corporate entities, such as Amazon or Disney, to maximize profit with each visitor. This allows them to accelerate the accumulation of capital power, while simultaneously restricting end user control and limiting the possibilities of how interacting with a service can be, in an act of cyber feudalism. The hyper-privatization required to enable this system continues to rob all of its users of its potential in the name of capital until it inevitably collapses in on itself from suffocating on its own interface restrictions, along with external market pressures. When this finally happens, the technology is almost never released to the public, either because its source has been lost or because of a complicated set of ownership changes, resulting in a complete loss of access. Examples of this effect include the downfall of many MMO games such as Toon Town and Club Penguin, and online services such as Tinypic or Geocities.

Disability and the UI Hierarchy

This problem of privatization reaches a critical breaking point when the disabled are involved. Disabled people not only have extremely specialized use cases that can vary from person to person, but they are also often limited in what kind of inputs or outputs they can interact with, forcing UI bottlenecks. In other cases, the way information is organized through outputs can be extremely difficult for certain types of disabled people to deal with. Many cases, disabled people may struggle even if standards are met, and are blamed for the failures of the UI limitations because they “meet accessibility software standards”. Users with such diverse needs create a need for not only just the “idea of the software” being brought to a physical product, but having multiple possible UI configurations to accomidate as many of these use cases as possible.

This requires for a UI design that accomidates not only the general user, but also highly specialized users, most of which cannot be accurately predicted. With no socialized solution across most computers, this necessitates in most situations a custom implementation for multiple complex modes of accessibility, something most developers have no experience with nor have time to learn. This level of responsibility on private developers is extremely high and often not met without working with contracting agencies, which introduces a new layer of inefficiency and can be very expensive. Because of these costs, many times accessibility isn’t integrated at all if the developers believe they can get away with it. Oftentimes, the only companies that can produces accessible software with any reliability on their own are large corporations. This allows these corporations to abuse accessibility as a means of leverage by exploiting disability for market share.

Accessibility market dominance is achieved by specifically focusing on obtaining high quality industry talent and concentrating resources integrating accessibility exclusively into environments. This can be seen how in this 2014 article Apple dominates blind mobile usershare in this study at over 86% and leads deaf usershare at 53%. Likewise, in this study, Apple dominates with 79% users exclusively using an iPhone, and 13% of users using both iPhone and Android. This robs both the blind and the deaf of what phone to use on the basis of physical disability. Another example of this sort of competition is Microsoft and Sony competing for more accessible game consoles, which locks off games based on accessibility, or Unreal Engine 4 integrating JAWS support with no open source license, putting pressure on Unity and other game engines to compete, most of which likely don’t have the niche resources to be able to react. Not only is this exploiting disability for capital gain, it creates unfair market competition that accelerates monopolization of multiple software markets. The final frontier is to push accessibility standards formed by this dominance into law, pushing out competitors who can’t afford their own investment in accessibility.

While accessibility standards do provide reasonable suggestions on how to implement some levels of accessibility, it rides on the pretense that end users should not have the right to change how they interact with their software. Ultimately, these accessibility standards exist more to protect the ability to privatize code and the needs of capital by encouraging individual responsibility for dealing with accessibility than to actually develop viable accessibility solutions for the disabled. The only reasonable way to deal with the needs of multiple kinds of UIs for all kinds of users is to eliminate the UI hierarchy, starting with releasing critical input/output components as open source, so they can be changed.

Open Source Vectors of Hierarchy

Open source, by itself, does not remove this hierarchy, although it can somewhat reduce it. Open source software only releases the source code to end users so that they can compile their own versions of it - when the design of compiled code is privileged, this comes with no requirement of specifications, development guidelines or documentation; as well as no guidelines towards project design. This resigns later developers to the arbitrary design decisions of the original developers, and forcing the end users to piece apart the code from the source, leading to a narrow understanding of the code. When software architecture is privileged, the authority of these architecture standards encodes itself deeply into all of the software produced for it, limiting its inherent structural design through specification. This stealthily sneaks hierarchical structure into code, even in parallel development, limiting the transmission of the development of UI and leads to accumulation of architectural debt over time.

Smaller projects, for example, are often only coded with a static structure to get the code running. When a project is developed with no particular framework in mind, it reinforces design techniques that grow more and more difficult to change over time. This results in the creation of “Code Debt” - abstract structures that reinforce themselves throughout a program through repeated integrations to the point of being almost impossible to remove. Projects that only focus on compiled code are unable to forsee accumulation of code debt and often are not aware until the project has developed to a nearly unmanagable point. Refactoring can reduce code debt by reallocating resources in a more efficient manner, but this is resource intensive, and the entropy of the project is embedded into how ultimately its codebase is developed as a single monolithic project. Focusing on software architecture can be a means to mitigate this problem. After all, static projects do have architecture, but that arcitecture changes constantly over time and is not composed with a specific design goal. However, architecture provides false security.

Linux, the more well known open source implementation of a UNIX kernel, is a very successful open source project created and maintained by Linus Torvalds. While the initial design of Linux was very clean and precise, the rigidity of its abstract structure lead to serious refactoring challenges, due to inability to predict future needs far into a project. A notable recent example involves socket input, which requires users to poll inputs directly. While remedied relatively recently, the work was extensive and required an enormous expenditure of manhours to overcome. Other examples of restrictions imposed by design in Linux are the rigidity of UNIX file permissions and module systems, both of which have architectures closely tied with the rigid abstract infrastructure that defines the Linux environment. Linux’s success demonstrates a project can be useful for many decades, causing substantial code debt to accumulate, thus mitigating much of the advantage open source provides.

In the case of CPython, the hierarchy is expressed differently. Guido van Russum, the original author, has very strong design ideals, reaching deep into the low levels of implementation. While these strong perspectives are well thought out and understandable, insistence on such strongly imposed design standards in practice leads to unnecessary limitations imposed on developers and forces them to use a rigid set of solutions that may over complicate implementations by developers. By expanding this rigid design philosophy throughout the CPython project, Russum has effectively closed off future potential by focusing on one ideal, forcing development of new versions to stagnate, as was evident by Python 3’s extreme development cycle.

In both, not only is the UI hierarchy imposed on the end users of both projects, but the hierarchy is imposed on developers trying to modify the project through the very way the project is organized, thus never resolving the hierarchy, and leading to serious project management issues.

Project Ownership and Hierarchy

Linux and CPython demonstrate how hierarchy can sneak itself into open source projects through private ownership of projects.

The most important way that both Linux and CPython assert structural hierarchy on its code is through the ownership of code. Both Linux and CPython are still privately owned - their license permits the reproduction of the code in a way that discourages closing off the source in the future. This causes social power to accumulate with the authors and owners of the code. Authors may exchange code ownership to another person or group, and authors and owners impose hierarchy in different ways. Authors impose hierarchy by creating the initial state of the code and embedding software design assumptions into the original architecture, while owners impose hierarchy by directing the future development of the software, imposing future design limitations. While parallel development helps mitigate these problems somewhat, because the organization that owns the original code has the most access to resources specifically knowledgable in the codebase, they still have an advantage that allows them to accumulate more development much more quickly than forks of can, forcing competing forks to either find niches or be lost.

Hierarchy in computing is a result of static structure being imposed and enforced on a computer system, and will lead to the development of the UI hierarchy. It is accelerated by increased private ownership of both code and projects by concentrating control in select groups. There is no true solution to this problem, since there is always some level of structure imposed in code, so development away from hierarchy is a continuous progression marked by occasional software revolutions. We have reached a point where we can clearly see how structure imposed by privatization directly encourages bad decision making and ultimately prioritizes abstract gains from code over the code itself. Revolutionizing the way that developers approach software design requires the recognition that end users should be developers too, especially when it comes to how they interact with our software through UIs. We have to overcome assumptions about software design that encourage concentration of ownership of resposibility and property in individuals. It will be extremely challenging and require a complete reunderstanding of how we approach software design.

I have some ideas, but those will have to wait a while. They’re still cooking.

Thank you to my friend Will for helping provide additional resources on technical information regarding Open-Source projects.

posted on 11:10:00 PM, 03/04/20 filed under: needs tech game theory [top] [newer] | [older]