Symbiotic Apps

Purism’s long-term goals have always been to make computers that are as convenient as they are respectful to the people that use them. The Librem products are an ethical platform and therefore should not discriminate against anyone; instead, they are meant to be inclusive of all human beings. In other words, everyone should find in their Librem a convenient and secure platform for their daily usage, and therefore accessibility should also be an important part of our ethical design roadmap.

We are aware that the road is long and that the Librem 5 is a challenging project, so we need some design foundations that favor convenience as much as it can lighten the development effort to get there.

Apps on existing platforms compete for your attention

With today’s smartphones, you usually get a minimal set of functionalities out of the box and go through installing diverse applications for your different needs. Usually those applications are proprietary and are designed around their own unethical business model. Therefore, they compete against each other for your attention. Each app has its own set of features and these features can only be used within the same application.

This can lead to a lot of redundancy and confusion in terms of functionality. A particularly blatant case is communication applications, where we see each application handling their own contacts logic, their own locked down and isolated protocol, and where a ton of applications will implement the same things for the same purpose (making calls and sending messages), with the focus typically being the flashiest application to attract and retain the most users. Let’s illustrate how ridiculous this is, conceptually:

../_images/reduntant_data_funct.png

Envisioning a harmonious app ecosystem

In the real, natural world, sustainable ecosystems are made of biological entities interacting together in harmony or symbiosis. This is what makes life possible over the long term.

The digital world of Free/Libre & open-source software, particularly in operating systems, is highly similar to the natural ecosystem. In this world, there is no such thing as isolating off or protecting a technology if you want to be part of the system. Business models and interests are completely different from the world of proprietary software. Best practices favor reuse and integration, improving user experience, reducing technical debt, increasing software quality and lowering development costs, with a “collaborative” system where different applications from different authors are made to work together.

The Purpose is the Feature

The idea behind the PureOS design guidelines is to replace the concept of standalone, independent and feature-competing applications with a concept of small, single-purpose, cross-integrated applications—that would interact between each other to provide a unified experience across the device (and beyond). Those small applications can be seen as “features” of the system. 1 purpose = 1 feature.

../_images/collab_eco.png

Therefore, the Human Interface Guidelines’ main principles regarding “features” development would be :

  • Don’t see applications as independent programs but as “features” that have a single purpose and that interact with each other.
  • One “feature” application is guarantor of the security of the data flow going through it. Only make your “feature” application share data with “trusted” features or networks and in a secure way.
  • Make a “feature” application focused on one single purpose (an email client is not an address book nor is it a calendar)
  • Make your “feature” application rely on existing features (an email client should rely on the existing address book and the existing calendar “features”)
  • Avoid redundancy. Don’t try to reinvent existing applications. Improve them instead.
  • Setup your “feature” application by default. Make it work out of the box.

Advantages

On the user’s side, the features of the device are easy to spot as they are made available through single-purpose applications displaying an obvious name. For example, the “Call” application is made to make calls, no matter the technology used behind that (e.g. Matrix, phone, VoIP). The “Messaging” application is used to send instant messages, no matter the technology used behind that (e.g. Matrix, SMS, XMPP). The “Contacts” application is used to manipulate and store the contacts information to be used by the “Call” and “Messaging” applications.

On the developer’s side, applications are as simple as they can be, the use cases are limited, all the logic that is not related to the main purpose of the application is delegated to other programs, which makes the application easier to design, implement and maintain.

Data belongs to the user, not the application

In this collaborative application system, where applications can interact with each other in harmony, data is not limited to the application’s logic anymore. Applications are acting as services, or “data providers”, to each other. Data can flow from one application to the other, from one device to another, from one network to another.

This concept implies the separation between data and functionality where the data belongs to the user only. The application that manipulates it is guarantor of its integrity and security.

Note

These are guidelines, representing an overall vision. Guidelines are here simply as a way to guide application design, and to suggest best practices for application developers in general. Given that a GNU+Linux distribution like PureOS is an open platform where thousands of applications are available independently (as long as they are freedom-respecting!), you are not obligated to conform to these design guidelines to be able to distribute your application through Debian and PureOS. Furthermore, these design plans represent a broad long-term plan, not necessarily a guarantee of what will be happening “immediately” in the first released version of the platform that ships, your mileage may vary, etc.