The first major version of aragonUI is finally out, and what a journey it has been! This post is meant to expose some of the principles we followed, what we’ve introduced, how to upgrade to 1.0, and where aragonUI is headed next.
If this is the first time you’ve heard of aragonUI, you can get started right away by reading the new “getting started” page.
A short history of aragonUI
When we started this project two years ago, the idea was to make a generic UI toolkit aiming to include any component related to Aragon projects: the website, the client, the apps, and maybe more. One library for everything: one look, one feel, one way to build interfaces. We wanted it to excel when applied to any of those contexts.
This vision worked great for a while, until it began to become apparent that a realignment was needed. On one side, the websites were evolving, dissociating their visual identity from our products. On the other side, it started to become clear that the main purpose of aragonUI was to assist Aragon app authors in building great UI experiences. That became the intent that would drive the next decisions for aragonUI.
Being able to build an Aragon app without aragonUI, and even without React, ensures that we maintain a diverse and future-proof ecosystem. This is why the idea of making aragonUI a mandatory library to build Aragon apps has always been avoided. Instead, we wanted to make its experience so good that it would become the default choice for many app authors, bringing in the process a great amount of visual consistency to the Aragon ecosystem.
Earlier this year, we initiated one of our most ambitious projects, UI-wise: initiating a complete overhaul of the way we approach our interfaces, starting with what would become a complete design system for Aragon products: aragonDS.
As we fleshed out our design system, it became apparent the Aragon client and its apps would need to go through a complete overhaul, with aragonUI implementing the changes needed in parallel, to mirror the component specifications defined by the design system. More than an independant UI library, aragonUI would become a reference implementation of aragonDS's component library. In the process, some components evolved while others were created or deprecated.
This effort was also an excellent opportunity to improve the focus of aragonUI: we wanted to reach a new level in developer experience for building Aragon apps. Authors shouldn’t have to wrap their app in anything more than a single component or worry too much about spacing or responsiveness. Components should be looking good by default. By making it about apps, it became possible to provide simple component names, like
Header, where the context of a component is already implied.
We decided that once finalized, this aragonUI conversion would be released as aragonUI 1.0.
But what is aragonUI?
Any project of this nature requires making frequent decisions at various levels. Even the smallest contribution can become quite challenging without a clear understanding of where the project is heading, what is urgent, or what is important. This is why having a clear and common understanding of what the project is, and often more importantly, what it is not, can help to focus the energy and start shaping a common vision about the project.
Up to this point, aragonUI was relying on a series of ideas that could be described as its DNA. They touch different areas and by no means constitute an exhaustive list. You can see it as a series of principles and ideas that act as a backbone for aragonUI.
A great UI library requires high quality parts
Pointing at things that could be improved in a user interface is often a much easier task than dissecting a great UI and understanding the pieces that work. This is because the details of a great interface tend to be dissimulated by their integration into the whole piece and the overall context being served.
Excellent UI platforms generally maintain a high and consistent level of quality at different levels: performance, animations, visual precision, quality of interactions, complete documentation, and API design. This is the kind of constant, global quality that aragonUI is aiming for.
Accessibility is an essential ingredient
The last idea of the Aragon Manifesto is stated as:
We are committed to a world in which every person can participate in these new organizational structures.
Our mission as Aragon contributors is to empower humankind as a whole, not only a fraction of it. This is only one of the reasons why the accessibility level of Aragon products will always be a priority. It obviously applies to aragonUI, which will keep progressing in that direction. Ensuring we are not excluding individuals is essential to the success of the Aragon mission.
Interactions should feel good
We humans tend to project our imagination onto the interfaces we use, to the point where pressing a virtual button on a cold, flat smartphone screen can sometimes feel oddly similar to the sensation of interacting with a real, physical button.
Shigeru Miyamoto, one of the most accomplished game designers in the world, describes this connection by using the japanese term Tegotae, which could be translated literally as “the hand feel”:
Tegotae is the word that you’re describing when you talk about that feel of a Nintendo game and it goes back to the focus on the notion of pressing a button and what happens on screen and how do you feel.
This powerful idea applies to any kind of virtual interaction. We want users to feel that Aragon interfaces are looking and behaving “right”.
Firstly, transitions should be fast, consistent, and natural. Thanks to the excellent react-spring, this is an achievable goal. Transitions should also work out of the box, so that authors can focus on their apps rather than solving animation problems.
Secondly, the interface should react immediately, the same way physical objects do. The UI should never freeze for any perceptible amount of time.
Thirdly, interactions should be predictable. Users shouldn’t be surprised by an object moving in an unexpected way or by an element behaving in a way different than what most people would expect.
Components should be adaptive
aragonUI is responsive out of the box, without much extra work from the author’s side. This is because every component is responsible for adapting itself to the environment. Not only do they adapt to the viewport size, but they can also adapt based on the context they are displayed in.
The general idea is to provide great defaults while always making sure that an override is accessible to an author if needed. For example, the Button component used in the Header will automatically show either its label or its icon, depending on the horizontal space available. But authors can override this behavior by setting its
display prop to something other than
auto. These cases are documented per component.
To keep up with the progress of Aragon
Subscribe to the Aragon newsletter
Get the latest project updates delivered right to your inbox