Category: Product Design

Design report #4: symbiotic applications

Purism’s long-term goal has 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 be discriminating 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; hence they compete against each other for your attention and have their own set of features to be used within the scope of the application only.

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:

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.

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 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.


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.

Please note: these are guidelines, representing an overall vision. Guidelines are there 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.

Librem 5 puzzle pieces starting to come together—graphics, adaptive applications, docs and SDK

The Librem 5 is a big project. And like a lot of big projects, as you probably know, it can appear overwhelming, until you can break the parts down into logical steps. Like a large puzzle scattered on a table, our team has been organizing and beginning to assemble all the pieces. This is very exciting to progress through the initial daunting scope, accepting the tasks, start working and then… after some time, solutions emerge and almost magically align.

In our previous blog posts we described what we were starting to work on, and these efforts began to prove themselves out significantly during our week-long hackfest where part of our software phone team gathered last week in Siegen, Germany. Read more

Design report #3: designing the UI Shell, part 2

Peter has been quite busy thinking about the most ergonomic mobile gestures and came up with a complete UI shell design. While the last design report was describing the design of the lock screen and the home screen, we will discuss here about navigating within the different features of the shell.

The mock-up on the right describes the main navigation principles. It shows the basic gestures that can be used to navigate through the different features of the shell.

From top to bottom:

  • (N) – Pulls down the full list of notifications.
  • (S) – Pulls down the full list of system settings.
  • (Q) – Reveals the most frequently used settings.
  • (W) – Quick launcher (to quickly access the communication features).
  • (A) – (3 seconds) Reveals the list of running applications.
  • (H) – Navigate back to the home screen.

And below are a few more mockups illustrating additional planned features of the Shell:

  • The multitasking overview screen that is revealed through the gesture (A) shows a carousel of all running apps along with their icons to make them easier to spot and access in a touch.
  • Swiping up from the bottom of the screen, from gesture (H), brings back the home screen
  • The “quick launcher” from gesture (W), in this example, is launching a list of (favorite) contacts for a quick access to the communications features.

An experience for people first, not just “app stores”

Now that we have defined the main features and gestures of the shell, it should be time to take care of the applications’ interfaces next.

If the Librem 5 was “Yet Another Android phone,” I would say “Go! Let’s make a bunch of apps!” But the Librem 5 is not just a regular phone, and Purism is very different from Apple and Google in term of philosophy and business model—they have been focusing on having the “biggest” app stores, selling apps, and mining data… and we don’t do that.

Therefore, before hastily moving forward with designing applications interfaces “like the other platforms”, not only must we study the current state of the mobile industry in term of User Experience, we must also try to think on how to improve it with a user-centric paradigm instead of necessarily app-centric. I think that, in some ways, there are many areas where the Librem 5 can bring greater simplicity, making iOS and Android look over-complicated in comparison. It may sound crazy to say that, but bear with me for a moment, we’ll get back to this later on.

By understanding a few concepts, we can try to define some human interface guidelines that will help getting a better user experience by default. This won’t prevent the phone to remain a highly customizable FLOSS platform—it will just help making the Librem 5’s “out of the box” experience more useful for everyone.

Librem 5 Phone Progress Report

Back from FOSDEM

Being at FOSDEM 2018 was a blast! We received a lot of great feedback about what we have accomplished and what we aim to achieve.  These sorts of constructive critiques from our community are how we grow and thrive so thank you so much for this! It helps us to focus our development. Moreover, I was very impressed by the appreciation that we received from the free software community. I know that relationships between companies, even Social Purpose Corporations—like Purism, and the free software communities are a delicate balance. You need to find a good balance between being transparent, open, and free on one side but also having revenue to sustain the development on the other side. The positive feedback we received at FOSDEM and the appreciation that was expressed for our projects was great to hear.

We are working really hard on making ethical products, based on free/libre and open source software a reality. This is not “just a job” for anybody on the Purism staff, we all love what we do and deeply believe in the good cause we are working so hard to achieve. Your appreciation and feedback is the fuel that drives us to work on it even harder. Thank you so much!

Software Work

As I mentioned before, we have the i.MX 6 QuadPlus test hardware on hand, so here are some photos of our development board actually running something:

On the right, you can see the Nitrogen board with the modem card installed. On the left is our display running a browser displaying the Purism web-page and below it a terminal window in which I started the browser. To put the resolution of the display into perspective I put a Micro SD card on the display:

Click to enlarge

The terminal window is about as big as three Micro SD cards! This makes it very clear that a lot of work has to be put into making applications usable on a high resolution screen and to make them finger friendly since the only input system we have is the touch screen. In the next picture I put an Euro coin on the screen and switched back to text console:

Click to enlarge

Concerning the software, we are working on getting the basic framework to work with the hardware we have at hand. One essential piece is the middleware that handles the mobile modem that deals with making phone calls and sending and receiving SMS text messages. For this we want to bring up oFono since it is also used by KDE Plasma mobile. We have a first success to share:

This is the first SMS sent through oFono from the iMX board and the attached modem to a regular mobile smartphone where the screenshot was taken. So we are on the right track here and have a solution that is starting to work that suits multiple possible systems, like Plasma mobile or a future GNOME/GTK+ based mobile environment.

The SMS was sent with a python script using the native oFono DBus API. First the kernel drivers for the modem had to be enabled followed by running ofonod which autodetects the modem. Next the modem must be enabled and brought online (online-modem). Once this was done sending an SMS was as simple as:

purism@pureos:~/ofono/test$ sudo ./send-sms 07XXXXXXXXX "Sent from my Librem 5 i.MX6 dev board!"

The script itself is very simple and instructive. Simulating the reception of a text message can also be done, with a command such as this one:

purism@pureos:~/ofono/test$ sudo ./receive-smsb 'Sent to my Librem 5 i.MX6 dev board!' LocalSentTime = 2018-02-07T10:26:19+0000 SentTime = 2018-02-07T10:26:19+0000 Sender = +447XXXXXXXXX

The evolution of mobile hardware manufacturing

We are building a phone, so hardware is an important part of the process. In our last blog post we talked a bit about researching hardware manufacturing partners. Since we are not building yet-another Qualcomm SOC based phone, but starting from scratch, we are working to narrow down all the design choices and fabrication partners in the coming months. This additional research phase has everything to do with how the mobile phone hardware market has evolved in the past years and I want to share how this all works with you.

In the early days of smartphones, a common case was that the main CPU was separated from the cellular baseband modem and that the cellular modem would run its own firmware when implementing all of the necessary protocols that operate the radio interface—at first it was GSM, then UMTS (3G) and finally LTE (4G). These protocols and the handling of the radio interface have become so complex that the necessary computational power for handling this as well as the firmware sizes have grown over time. Current 3G/4G modems include a firmware of 60 or more megabytes are becoming more common. It did not take long before storing this firmware became an issue as well as at run time since this requires significant increases of RAM usage.

Smartphones usually have a second CPU core for the main operating system which also runs the phone applications and interacts with the users. This means that your device must have two RAM systems as well, one for the baseband and one for the host CPU. This also means you need two storages for firmware, one for the host CPU and one for the baseband. As you may imagine, getting all of these components working together in a form factor small enough to fit into someone’s hand takes a lot of development and manufacturing resources.

The advent of cheap smartphones

There is extreme pressure about the cost of smartphones. In today’s commodity market, we see simple smartphones starting at prices less than $100 USD.

The introduction of combined chips, with radio baseband plus host CPU on one silicon die inside one chip, massively reduced costs. This allows the host CPU and baseband to share RAM and storage. Since the radio can be made in the same silicon process as the host CPU, and both can be placed in a single chip package, we see substantial cost reduction in the semiconductor manufacturing as well as the cost of manufacturing the device. This saves you from having to use a second large chip for the radio itself, an extra flash chip for its firmware, and possibly an extra RAM chip for its operation. This does not only reduce the Bill of Materials (BOM), but also PCB space, and it enables the creation of even smaller and thinner devices. Today we see many big companies offer these types of combined chipsets—such as Qualcomm, Broadcom, and Mediatek to name a few.

These chips caused a big shift in the mobile baseband modem market. Formerly it was common to find discrete baseband modems on the market that were applicable for mobile battery powered handsets like the one we are developing. But since the rise of the combined chipsets, the need for separated modems has dropped to a level that does not justify their development as much. You can still find modem modules and cards but these modules are usually targeted for M2M (machine to machine) communication with only limited data rates and most of them do not have audio/voice functions. They usually come in pretty large cards, such as the miniPCIe or M.2. For us this means that our choice of separated baseband modems suitable for a phone is narrowed.

What this means for OEM, ODM or Build it Yourself

All of this consolidation has an impact on hardware manufacturers and our choices. Pretty much all current smartphone designs by OEM/ODM manufacturers are based on the combined chipset types; this is all they know and it is where they have expertise. Almost no one is making phones with separated basebands anymore, and the ones who do are not OEMs nor ODMs. The options are further limited by our requirement not to include any proprietary firmware on our host CPU (which we wrote about before): most fabricators are unfamiliar with i.MX 6 or i.MX 8 and do not want to risk a development based on it, which narrows our hardware design and manufacturing partners to a much smaller list.

However, we have some promising partners that we will continue to evaluate, and we are confident that we are going to be able to design and manufacture the Librem 5 as we originally specified. We just wanted to share with you why making this particular hardware is so challenging and why our team is the best one to execute on this design. To continue to discuss with some of the manufacturers and providers, Purism will visit Embedded World, one of the world’s largest embedded electronics trade shows, in Nürnberg (Germany) in the beginning of March. And, as usual, we will continue to keep you updated on our progress!

Good news with our existing evaluation boards

We have been patiently waiting for the i.MX 8M to become available, all according to the forecast timeline from NXP. In the meantime, we have started developing software using the i.MX 6 QuadPlus board from Boundary Devices, specifically the NITROGEN6_MAX (Nit6Qp_MAX) since it is the closest we get to production devices before NXP releases the i.MX 8M. We have a Debian Testing based image running as a testbed on these boards while the PureOS team is preparing to build PureOS for ARM and ARM64 in special.

On these evaluation boards we have all the interfaces that we need for software development:

  1. Wi-Fi
  2. Video input and output
  3. USB for input devices
  4. Serial console and a miniPCIe socket with SIM card connected for attaching a mobile modem
  5. At the moment, we are using a Sierra Wireless MC7455 LTE miniPCIe modem card for development, which uses a Qualcomm MDM9230 baseband modem chip. This card is basically a USB device in a mPCIe form factor, i.e. we do not actually use the PCIe interface.
  6. An extremely nice display to our kits using an HDMI-to-MIPI adapter board. The display is a 5.5″ AMOLED display with full-HD resolution with the native orientation as portrait mode.

This hardware setup allows us to start a lot of the software development work now to ensure our development continues in parallel until we have the i.MX 8M based hardware in hand.

Next on our to-do list: phone calls!

Designing the Mobile Experience with Convergence in Mind

It is always great to have the opportunity to discuss face to face with community members to get the pulse of what their thoughts are and suggestions they might have for the Librem 5 project. As such, I was happy to spend time discussing at length with people attending FOSDEM this week-end. Comments from the many supporters made me realize that there are some points regarding goals and vision, in terms of design for the entire Librem line, that needed to be expanded upon and clarified. Keep in mind that although the vision for our short and long-term design goals for the Librem 5 is becoming increasingly clearer, it is of course still “work in progress” from a design perspective; things are not set in stone and therefore we are listening (and responding) to the community’s feedback.

Convergence, for Purism, is a long-term goal to unify the human experience across different devices.

  • A user interface is made of a layout and interactive elements. Different devices using different input and output technologies will have different requirements for layout and interaction. In this case, our approach will consist in designing “responsive” (adaptative) layouts and interaction patterns that will allow modern apps to adapt themselves to the device that it is running on. We don’t have to port/adapt every single existing desktop app under the sun to achieve that goal though, and our partners in the GNU+Linux community have aligned goals with this direction.
  • That approach of convergence is also about the simplicity of accessing the same data and services between different devices, transparently.
  • Part of our plan for convergence is about helping define some consistent Human Interface Guidelines and optimizing the development tools & documentation, in order to help developers create a great experience across devices.

The implementation of our design involves the use of existing technologies, and the UI+UX design itself is not made with a specific technology in mind. Our design work is an attempt to define a set of Human Interface Guidelines that rely on the Ethical Design manifesto and our requirements for security and privacy. The technical details of its implementation are out of the scope of this design report and should be discussed with the development team.

Designing a Mobile Experience

Over the last two weeks, we have been thinking about general human interaction principles for the Librem 5. Our idea is to define the best possible mobile interaction design principles and combine it with an “optimal” mobile shell experience. While what you will see below is simply a high-level overview of work in progress that may change before final public versions, it is setting the stage, and is a good starting point for our upcoming work, such as the communications features that I’ll soon write about in a separate blog post.

Some Basic Principles

We think that a good mobile experience should define convenience and comfort when using the device. It should take into account the hardware in all its aspects along with the many different use cases. In that regard, it is important to define principles that are adapted to the physical device. One of these principles is that one-handed usage of a phone is frequent, and so our interaction design should take this fact into account.

One should be able to easily access the most important features of the phone when holding it with one hand; it supposes touching the screen with the thumb only. That doesn’t necessarily mean that all the screen surface and features must be accessible by the thumb (given the planned 5.5″ screen size, that would not be physically possible), but that the lower area is preferable to access the most useful phone features by default. Those features would include answering an audio or video call, reviewing notifications, unlocking the phone, accessing the home screen, requesting a search or launching the most frequently used applications.

To remain useful for both right and left-handed persons, the optimal area should favor the bottom half of the screen while also avoiding going too far towards the edges (that may be more difficult to access).

The size of the touch (tap) area is also something to take into account in order to give the user the best precision when interacting with the user interface.

Action targets like links, buttons, sliders and other interactive UI elements should take into consideration a sufficient surface size to be used with comfort and precision.

A First Look at the Shell

Peter K., our lead UI/UX designer, has been working on adapting these basic principles to the overall UI shell experience :

The main navigation happens at the bottom half of the screen, and similarly the majority of the interaction with the Lock Screen would happen in the lower half of the screen. When unlocked, the phone would reveal the Home Screen and show the most frequently used applications (or features) of the phone by default. Some useful widgets may use the remaining space (our example is showing music controls and web search widgets). Swiping up the frequently used applications icons reveals the full list of applications as well as the “main” search field, that is also accessible at the bottom of the screen. Less recurrent gestures, like accessing the settings or the detailed list of notifications, are available in the upper part of the screen.

More to Come

This was a quick appetizer regarding the ongoing design effort. Upcoming work will be about finalizing the shell experience and designing privacy-respecting communication features, so stay tuned!

Librem 5 Phone Progress Report

The Librem 5 and recent industry news

Lately, news headlines have been packed with discussions about critical CPU bugs which are not only found in Intel CPUs, but also partially in AMD CPUs and some ARM cores. At the same time, some of our backers have voiced concerns about the future of NXP in light of a potential acquisition by Qualcomm. Therefore you might be wondering, “Will the Librem 5 be affected by these bugs too?” and “will the Purism team get the i.MX 8 chips as planned?”, so let’s address those questions now.

Not affected by Spectre/Meltdown

At the moment we are pretty confident that we will be using one of NXP’s new i.MX 8 family of CPUs/SOCs for the Librem 5 phone. More specifically we are looking at the i.MX 8M which features four ARM Cortex A53 cores. According to ARM, these cores are not affected by the issues now known as Spectre or Meltdown, which ARM’s announcement summarizes in their security update bulletin.

So for the moment we are pretty sure that the Librem 5 phone will not be affected, however we will continue to keep an eye on the situation since more information about these bugs is surfacing regularly. In this respect we can also happily report that we have a new consultant assisting our team in security questions concerning hardware-aided security as well as questions like “is the phone’s CPU affected by Spectre/Meltdown or not”.

Qualcomm possibly buying NXP: not a concern

For quite some time there have been rumors that Qualcomm might have an interest in acquiring NXP. Since we will be using an NXP chip as the main CPU, specifically one of the i.MX 8 family, we are well aware of this development and are watching it closely.

Qualcomm is an industry leader for high volume consumer electronics whereas NXP targets lower volume industrial customers. This results in pretty different approaches concerning support, especially for free software. Where NXP traditionally is pretty open with specifications, Qualcomm is rather hard to get information from. This is very well reflected by the Linux kernel support for the respective chips. The question is how would it affect continued free software support and availability of information on NXP SOCs if Qualcomm acquires NXP?

First, it is unlikely that this deal will happen at all. Qualcomm had a pretty bad financial year in 2017 so they might not be in the financial position to buy another company. Second, there is a rumor that Broadcom might acquire Qualcomm first. Third, international monopoly control organizations are still investigating if they can allow such a merger at all. Just a few days ago the EU monopoly control agreed to allow the merge but with substantial constraints, for example Qualcomm would have to license several patents free of charge, etc. Finally, there are industry obligations that NXP cannot drop easily: the way NXP works with small and medium sized customers is a cornerstone of many products and customers; changing this would severely hamper all of those businesses involved, and these changes might cause bad reputation, bad marketing and loss of market share.

So all in all, this merger is not really likely to happen soon and there would probably not be changes for existing products like the i.MX 8 family. If the merger happens it might affect future/unreleased products.

Development outreach

In addition to working on obtaining i.MX6QuadPlus development boards to be able to work properly, the phone team is also intensively researching and evaluating software that we will base our development efforts on during the next few months. We are well aware of the huge amount of work ahead of us and the great responsibility that we have committed to. As part of this research, we reached out to the GNOME human interface design team with whom we began discussions on design as well as implementation. For example, we started to implement a proof of concept widget that would make it much easier to adapt existing desktop applications to a phone or even other style of user interface. What we would like to achieve is a convergence of devices so that a single application can adapt to the user interface it is currently being used with. This is still a long way ahead of us, but we are working on it now. We will meet up also with some GNOME team members at FOSDEM to discuss possible development and design goals as well as collaboration possibilities.

The mobile development work for KDE/Plasma will primarily be performed by their own human interface teams. Purism will be supporting their efforts through supplying hardware and documentation about our phone development progress as it is happening. This will help ensure that that KDE/Plasma will function properly on the Librem 5 right from the factory. To understand better where we’re headed with GNOME and KDE together, take a look at this blog post.

We also reviewed and evaluated compositing managers and desktop shells that we could use for a phone UI. We aim to use only Wayland, trying to get rid of as much X11 legacy as we possibly can, for performance issues and for better security. From our discussions with GNOME maintainers of existing compositors and shells, we may be better off igniting a new compositor (upstreamed and backed by GNOME) in order to avoid the X11 baggage.

On the application and middleware side of things, we have generated an impressive list of applications we could start to modify for the phone to reach the campaign goals and we have further narrowed down middleware stacks. We are still evaluating so I do not want to go into too much detail here, in order not set any expectation. We will of course talk about this in more detail in some later blog posts.

Meeting with Chip Makers

As the CPU choice is pretty clear lately, we are going to have a meeting with NXP and some other chip makers at Embedded World in Nürnberg, Germany, at the end of the month. This is very encouraging since we worked for months on getting a direct contact to NXP, which we now finally have and who we will meet in person at the conference. The search for design and manufacturing partners is taking longer than expected though. Our own hardware engineering team together with the software team, especially our low level and kernel engineers, started to create a hardware BOM (bill of material) and also a “floor plan” for a potential PCB (printed circuit board) layout, but it turns out that many manufacturers are reluctant to work with the i.MX 8M since it is a new CPU/SOC. We have, however, some promising leads and good contacts so we will work on that.

Purism Librem 5 team members attending FOSDEM

By the way, many Purism staff members will be at FOSDEM this week-end, on the 3rd and 4th of February. In addition to the design and marketing team, PureOS and Librem 5 team members will be there and we would love to get in touch with you! Purism representatives dedicated to answering your questions will be wearing this polo shirt so you can easily recognize them:

Librem 5 Phone Progress Report – A Design Team Assembles

We have spent the last two months building our design team for the Librem 5 Phone project. We have been studying the current state of mobile design within the free software community as well as large companies that have shown success in mobile. We have been in the planning phases of development attempting to produce an ethically designed device and now that we have a working prototype we have shifted to the process of designing User Interfaces (UI) and User eXperience (UX) for the Librem 5.

New members on the design team

Peter K’s Concept Art

Upon successful completion of our funding campaign, we started to look for a Designer to take care of the user experience for the Librem 5, and a web developer to help us improve the look & feel (and more technical parts) of our website in general. Today, I’m glad to finally welcome them publicly!

  • Our new UI & UX Designer is Peter Kolaković, who is very talented and had already gotten involved during the campaign by creating amazing concept art (that we ended up displaying on the campaign page and that became the basis for our potential look and feel of the Librem 5).
  • Our new Web Designer is Eugen Rochko, the web development wizard who already proved his skills by creating Mastodon.

We had a huge amount of talented and motivated applicants who were perfectly aligned with our philosophy of digital ethics, and so picking only two was a very difficult decision to make. Thank you to all of those who applied! We appreciate your interest, motivation, and ideas!

Unified look for PureOS devices

Peter has also been working on the look and feel of PureOS in an effort to make our systems convergent across devices: phone, tablet and laptop.

Our approach to convergence is that mobile is the motivating factor for all other platforms. We are aware that usability is different from a small touchscreen to a laptop monitor with a mouse and keyboard. We want to improve the user experience through ease of use, by creating a graphical environment that doesn’t require a steep learning curve when switching between devices. This approach is also helpful to developers who don’t want to maintain too many different outputs. Mobile design brings efficiency and simplicity first.

The general appearance of the user interface we’ll be designing is expected to follow current visual design approaches in the mobile industry. We expect our design to have a minimalistic aesthetic by default.

We are starting work on a dark theme (a “light” one will be designed as well). Here are a few mockups that we are working on (click to enlarge):

Community involvement approach

We want any of our Librem 5 UI/UX design and development work to be a direct contribution back to the parent projects that they are based on. You may be aware that we have partnered with both the KDE and GNOME projects, and so we wish to make the Librem 5 a mobile platform where the user can have a choice of Desktop Environments. Of course, KDE and GNOME are currently at fairly different levels of development with regards to mobile user experience:

KDE Mobile UI Example
  • KDE already has a beautiful and full-featured mobile interface (that our dev team is busy on making work on the Librem 5 hardware). Whatsmore, from a design standpoint, the KDE design team has done a great job developing a set of clean, touch driven user interfaces that make it a pleasant and functional mobile environment already; there is not much to add to KDE except for a graphical touch interface specific to PureOS. Purism’s contribution to KDE may be generally focused on hardware integration and testing, rather than design.
  • GNOME developers’ resources have not been focused on mobile user experience per se, so there is more work required to make GNOME production ready for a convergent Librem 5. In an effort to bring convergence across our devices which already run PureOS with GNOME, we are hoping to contribute design and software development efforts to the GNOME project. Our teams will develop and design the missing mobile components and improve the existing ones.

This is what free software is all about—not just taking existing work “as is” but adjusting and improving things that we send back for everyone to benefit from. We’re looking forward to giving development back to these two free software giants!


As I said in a previous post, we are working on producing an “ethical design” that:

  • Respects Human Rights by using free/libre technologies and contributing to them for the profit of everyone.
  • Respects Human Effort by unifying the user experience, making convergent designs based on a “Mobile First” approach that favors efficiency and simplicity.
  • Respects Human Experience by designing a modern, clean and efficient look for PureOS.

Librem 5 Phone Progress Report – The First of Many More to Come!

First, let me apologize for the silence. It was not because we went into hibernation for the winter, but because we were so busy in the initial preparation and planning of a totally new product while simultaneously orienting an entirely new development team. Since we are more settled into place now, we want to change this pattern of silence and provide regular updates. Purism will be giving weekly news update posts regarding the Librem 5 phone project, alternating progress reports on two fronts:

  • from the technology development point of view (the hardware, kernel, OS, etc.);
  • from the design department (UI+UX), and our collaboration with GNOME and KDE.

To kickoff this new update process, today’s post will discuss the organizational and technological progress of the Librem 5 project since November 2017.

New Team

Just after our successful pre-order crowdfunding campaign (by the way, thank you to all of the backers!) we started to reach out to people who had applied for jobs related to the Librem 5 project. We had well over 100 applicants who showed great passion for the project and had excellent resumes.

Our applicants came from all over the world  with some of the most diverse backgrounds I have ever seen. Todd Weaver (CEO) and myself did more than 80 interviews with applicants over a two weeks period. In the end, we had to narrow down to 15 people that we would make offers to; it was with great regret that we had to turn down so many stellar applicants, but we had to make decisions in a timely fashion and unfortunately the budget isn’t unlimited. During the weeks that followed, we negotiated terms with our proposed team members and started to roll new people into the team (with all that involves in an organizational setting). All of the new team members are now on board as of January 2018. They are not yet shown on our team page, but we will add them soon and make an announcement to present all the individuals who have recently joined our team.

As amazing as our community is, we also received applications from individuals who are so enthusiastic about our project that they want to help us as volunteers! We will reach out to them shortly, now that the core team is in place and settled.

There are so many people to thank for the successful jump start of our phone development project! It was amazing for us to see how much energy and interest we were able to spark with our project. We want to give a big thank you to everyone for reaching out to us and we really appreciate every idea and applicant.

CPU / System On Chip

Block Diagram i.MX6

During our early phase we used a NXP i.MX6 SOC (System On Chip) to begin software evaluation, and the results were pretty promising. This was why we listed the i.MX6 in the campaign description. The most important feature of the i.MX6 was that it is one of only a handful of SOCs supported by a highly functional free software GPU driver set, the Etnaviv driver. The Etnaviv driver has been included in the Linux mainline kernel for quite some time and the matching MESA support has evolved nicely. Briefly after our announcement we were contacted by one of the key driving forces behind the Etnaviv development effort which provides us with valuable insight in to this complex topic.


Block Diagram i.MX8

Further work with the i.MX6 showed us that it still uses quite a lot of power so when put under load it would drain a battery quickly, as well as warm up the device.

NXP had been talking about a new family of SOCs, the i.MX8, which would feature a new silicon processor and updated architecture. The release of the i.MX8 had been continuously postponed. Nevertheless, once we realized that the i.MX6 might be too power hungry, the i.MX8 became appealing to us. Hardware prototype operations are always tricky because you have to plan for emerging technologies that you meld with existing parts or materials. Components from original manufacturers sometimes never get released, are discontinued or the availability from the factory grinds to a halt for reasons beyond our control. This is the function of engaging in prototype development so that we can suffer the slings and arrows for you to provide the customer the best possible end product. We have been in active communication with all of our suppliers preparing a development plan that is beneficial for all of us.

At CES in Las Vegas, NXP announced the product release dates for their new SOC, the i.MX8M, along with a set of documentation. This is currently the most likely candidate we will use in the Librem 5. We are very excited about this timely announcement! At Embedded World in Nürnberg, Germany, NXP will announce details and a roadmap. We will be attending and discuss with NXP directly about the i.MX8M for the Librem 5.

We have also decided to use AARCH64, a.k.a. “ARM64”, for the phone software builds as soon as we have i.MX8 hardware. A build server for building ARM64 is now in place and the PureOS development team is beginning to work with the Librem 5 development team on the build process. Adding a second architecture for the FSF endorsed PureOS—that will run on Librem laptops as well as the Librem 5 phone—is a major undertaking that will benefit all future Librem 5 phone development.

Prototype Display for Development Boards

Since the i.MX8 is still not yet easily available, and in order not to unnecessarily slow development progress, we need similar hardware to start developing software. We switched to an i.MX6 Quad Plus board which should provide similar speed for the GPU to what we will find in the i.MX8M. From our contact from the Etnaviv developers we know that they are heavily working on the i.MX8M support so we can expect that Etnaviv will be working on it within the year.

One of the big tasks of our software and design teams, working with our partners (GNOME, KDE, Matrix, Nextcloud, and Monero), will be to create a proper User Interface (UI) and User Experience (UX) for a phone screen. The challenges are that the screen will be between 5″ to 5.5″ diagonally with a resolution of up to full HD (1920×1080), and a functional touchscreen! The amazing teams developing GNOME and KDE/Plasma have already done a great job laying the groundwork technologies and setting up this kind of interface to build, develop, and test with. With such great partners and development teams we are confident that we can successfully integrate the freedom, privacy, and security of PureOS with phone hardware to provide a beautiful user experience.

To help with development, we are already in the process of sourcing components to attach 5.5″ full HD displays to our development boards. Our development boards are already booting a mainline kernel into a Wayland UI nicely. We are evaluating similar displays from several manufacturers. We found a supplier for a matching adapter logic board (HDMI to MIPI). Our hardware engineer has already designed an additional adapter for interfacing the display’s touchscreen so that we will realistically have a 5.5″ full HD screen with touch capability on our development boards.

Potential Manufacturing Sites

The overall plan is to have a custom device manufacturing process setup somewhere where we can manufacture our own devices. Since November of last year we have been intensively researching and evaluating potential manufacturing partners. So far we have been in contact with over 80 potential fabricators and are in the process of negotiating capabilities and terms. No decision has been made yet. We have some promising prospects from all over the world, including Asia, Europe and the USA, and we plan on visiting some of these sites in person possibly by the end of February or March.

Cooperative Relationships

Now that the development team is in place we will be reaching out to our partners. Our UI/UX design team along with phone dev team are working with the GNOME UI/UX team to develop a path forward for mobile interfaces. We will also reach out to others who have partnered with us during the campaign, such as the KDE/Plasma team, Matrix, Nextcloud, Monero and many more.


I hope that the fog has been lifted, and we have answered questions you might have or assuaged fears of our silence. We hope that you enjoyed this first dive into our development process. We here at Purism are all very excited about the Librem 5 phone project, as we are passionate about all of our products, with the phone holding a special place in our hearts and those of the Free Software community. That’s what makes us different from companies rolling out “yet another Android phone”, swapping color palettes or removing headphone jacks under the guise of “innovation”…

See you next week for more news on the Librem 5 project!

We love Ethical Design

In our wish to bring our contribution to the betterment of society, wherever we plan to work on refining our products or existing software, we will conform to the Ethical Design Manifesto. Our philosophy and social purpose have always been in perfect unison with the principles stated in the Ethical Design Manifesto, and having it as part of our internal design team’s policy is a good way to make sure that we always keep it in mind.

What is Ethical Design?

The goal of “ethical” design is to develop technology that is respectful of human beings whoever they are. It encourages the adoption of ethical business models and, all together, it is favoring a more ethical society.

According to the manifesto, ethical design aims to respect:

  • Human Rights: “Technology that respects human rights is decentralised, peer-to-peer, zero-knowledge, end-to-end encrypted, free and open source, interoperable, accessible, and sustainable. It respects and protects your civil liberties, reduces inequality, and benefits democracy.”
  • Human Effort: “Technology that respects human effort is functional, convenient, and reliable. It is thoughtful and accommodating; not arrogant or demanding. It understands that you might be distracted or differently-abled. It respects the limited time you have on this planet.”
  • Human Experience: “Technology that respects human experience is beautiful, magical, and delightful. It just works. It’s intuitive. It’s invisible. It recedes into the background of your life. It gives you joy. It empowers you with superpowers. It puts a smile on your face and makes your life better.”

Growing the seed of an ethical society

Working towards an “ethical society” may sound like fighting windmills. I personally see it as a global, constant yet disorganized wish that nonetheless tends to materialize from time to time through a common concerted effort. I don’t think that this effort is about changing some thing because of its unethical nature; it has nothing to do with a fight. Instead, it is about growing the seed of a more ethical thing that would exist next to it.

In line with this goal and our social purpose is the fact that we aim to work in an “upstream first” way as part of the Free Software community; in order to contribute to the common effort toward growing this ethical seed, any software development and improvement on top of an existing project is intended to be discussed and co-developed upstream first. We don’t want to reinvent the wheel and fork existing projects just because we don’t like the colors of the paint on the wall! This would only fraction the community’s resources and add confusion for users.

There are so many amazing free software projects that share our philosophy, and we hope to contribute while also ensuring these pieces of software respect human rights, human effort and human experience. These are my guiding principles for Purism’s UI and UX design projects.

Announcing the Librem Phone Ringtone Contest winners

As part of our Librem 5 phone campaign page, we included a public ringtone contest. The response was overwhelming, and our team did not have an easy task of picking winners: we had to listen and rank over 150 sounds sorted in 5 categories! The most intense battle took over the ringtone category, where the winner won by merely 3% of our votes. Now that the list of winners and runner-ups is final, we will contact winners to inform them that they won a Librem 5 phone! Here are the top-ranked entries we received.

Read more