Why Does “App” Still Exist?A meta-UX reflection of the past decade of apps

What characterizes the digital world of the 2010’s? Most would agree with Web 2 and a world of apps. But whatever prosperity it seems to be does not prevent me from, alternatively, considering our current world of apps as an ad hoc mess. It has been practically obvious that no modestly sized group of experts would agree on the categorization of apps on their home screens. (Pointing at Apple.) Yet our ability to navigate this world of apps proves the presence of a certain logic, which states that each app has its own logic. Intrinsically, as a co-product of the current mode of relationship between online services and users, this model of apps will not serve any much-needed change against itself. (Now, take a moment to realize that the first choice you make after unlocking your phone perfectly manifests the status of this industry.)

Unless we determine to change it. But what change is needed? What is even that presumably better system? Unfortunately, I am not yet able to form concrete, detailed design to answer that, and my intention with this article is to give you an intuitive understanding. However, a concrete design would significantly involve logic and semantics. For those who love to see some sort of textbook definition, your wish is granted at the end of this article.

The Evolution of a Top-most Concept

Until the beginning of mobile computing, the usage of systems required a very central cognition: the distinction between programs and data. Usually, users open the file explorer to a location containing only their personal files, while a separate menu shows a list of programs, which themselves are kept somewhere outside of the user’s data directory. Typical usage would be either opening up a program and selecting a file to work with, or opening a file with a registered program. From the perspective of an engineer, doing so absolutely makes sense.

The invention of the concept of app, first and foremost, rejected the idea that program and data should be treated separately. This has, of course, brought us a diverse world of easy-to-use functionalities. But app quickly got further than that. The data does not have to be stored on your device anymore, because the app only provides the interface to using the online functionality as a whole, and suddenly very complicated information exchange comes in. They are baked into the concept, immediately invalidating the data/program pattern. In the end, the functionality is the only thing perceived by the user, much like an enclosed class. Let’s call these target elements.

The client software is also technically enclosed in its own environment for code execution. Anywhere outside of that, an app needs to make system API calls, for actions from reading a contact to exposing a file. All the other concepts have since stemmed from this top-level app concept, including its technical aspects. We introduced notifications, and later permissions, shared storage, widgets, and of course those icons on your home screen; URL handling apps, pairing apps (rather than activities) on dual-screen devices…. The list is endless, and all circumventing direct organization of the target functionality.

An Ad hoc Pile of Apps

Furthermore, a fact that never changed since the invention of app is that apps are ad hoc. The following are some of the points I am able to summarize:

  • Nothing is interoperable by default, including indexing. Similarly, any data sharing action across apps is considered a significant, explicit context switch that is difficult to reduce.
  • Procedures, no matter how regular and redundant, have to be programmed explicitly. This is especially the case around OS API calls, which are designed in an engineering sense and considerations for the user are added by the app developer. For example, “Your network/Bluetooth/USB is broken” messages are paired with tremendous troubleshooting instructions made by the app developer. Contrast this with a humble perror which will even print the reason of the error to you.

These consequences should be directly attributed to “There is an app for that,” where “that” implies a presumably cozy corner of your digital life that need not be interoperable or subjected to further analysis. I am not giving further comments on this quote, because I want to let you see the direction in which things are changing that is going to take us beyond the app.

The Ongoing Shift

In 2016, Android got richer notifications, adding visual media and a direct reply function. In 2017, Notification Categories. In 2018, Slices (Does anyone still remember this?), which are small pieces of interactive UI that were supposed to be included by other interfaces. In 2021, a large number of Android widgets were updated, which incidentally happened after the iOS 14 widget update in 2020. It was the most recent change that got wide appreciation. All of these have brought targets closer to the current context.

An Asystematic Change

Our current change is very partial. On an asystematic thought, we may want to bring more targets to our home screen to apparently bring the target elements closer, hence the app widgets and shortcuts. We also try to make dashboards (Designers love dashboards and feeds!) without really figuring out why. I shall argue that our current optimizations cannot arrive at its very core goal without us first realizing what we are doing. We are mixing the two systems, one with an explicitly stated top-level app concept that is not semantically helpful by itself, and the other implicit, anti-well-formed, and increasingly used, therefore almost dangerous.

Obviously, all of these features have created a so-called better user experience, by saving the user from an otherwise boringly redundant procedure. But can that be explained? We should now be asking, why is that considered a better user experience?

The Supposed Destination

All of these optimizations are what I consider to be part of an inevitable shift to an overarching UX approach that pivots around target elements, which intrinsically disregards the app concept. Because app is not an element we work with directly, UX increasingly circumvents that concept and takes you to the thing. This may or may not have been done consciously. But at the end of this change, the UX should reflect cognition; that is, things work on your device as you would think they logically are, without any designer or engineer mindset, and without any unnecessary entities (apps).

This new architecture should integrate target elements on the client side through semantics, as well as intuitively conveying the semantics to the user. This should be achieved with minimal user configuration and permissions granted to each client executable.


Posted

in

by

Tags: