DEV Community: Maxi Stahl

Anatomy of a Design System

Maxi Stahl — Thu, 13 Jul 2023 13:41:56 +0000

In the previous article, we explored the significance of establishing a shared language between developers and designers and introduced the fundamental concepts of a Design System (DS). Building upon that foundation, this article will delve into creating a basic structure for a DS from both the UI-UX and Development perspectives. By aligning these two crucial aspects, we aim to develop a comprehensive understanding of how to structure and implement a successful Design System.

The Design System Structure

In addition to defining a basic structure for a Design System, the collaboration between UI-UX and Development teams brings forth numerous benefits. By working together, the speed of UI creation is significantly enhanced, allowing for rapid prototyping and iteration. This streamlined process not only accelerates development but also ensures a consistent and cohesive user interface. Furthermore, the collaborative efforts foster efficient implementation, as developers can leverage the predefined components and styles from the Design System, reducing redundancy and minimizing coding effort. The synergy between UI-UX and Development teams ultimately results in a more efficient and effective workflow, delivering high-quality user experiences in a faster and more scalable manner.

The Design System Structure from the UI-UX Perspective

The Design System Structure from the UI-UX Perspective involves a progressive workflow that starts with defining tokens. Since most of the basic atoms are already established by default (basic HTML tags), the designer's focus shifts to creating and refining the tokens. Subsequently, the tokens are applied to different atoms, and the designer begins iterating on special components. This iterative process continues until a solid foundation is established, forming the basis for working on variants, themes, and layouts. This approach guarantees a methodical and iterative strategy for constructing the Design System, empowering the UI-UX team to develop uniform and harmonious designs while upholding adaptability and expansiveness across the design process.

We choose Figma as our tool to create the Design System Structure.

To see an example of this workflow in action, you can take a look at the Figma file that I created for this serie.

This is the moment to add a couple of rules that will help you to create a better Design System:

First one: "Every business rule should be implemented in the code, not in the Design System". This rule will help you to create a better Design System, and to avoid the creation of a "Frankenstein" Design System.
Second one: "Order and consistency are the keys to success." Do not create a Design System with a lot of components, create a Design System with a few components, but with a lot of variants.
Third one: "Create visual behavior, not business behavior." Think about the rules that you need to place a component in a container. Meaning, the container should handle the position of the component, not the component itself. In the example of a Card, the button could be centered, but in another container (let say a form) the button could be aligned to the right.

The Design System Structure from the Development Perspective

The Design System Structure from the Development Perspective involves translating the Design System's structure into code. It requires making key decisions regarding the organization of styles and resources, selecting the development framework, and establishing coding and implementation guidelines. This process ensures a consistent and efficient development workflow, where developers can easily access and utilize the predefined components, styles, and resources provided by the Design System. By defining a clear roadmap for coding and implementation, the Development team can maintain code consistency, streamline development efforts, and enable seamless collaboration between team members. This approach lays a solid foundation for building scalable and maintainable software solutions while adhering to established coding practices and leveraging the power of the Design System.

We choose React as our framework to create the Design System Structure.

Here is an example of the Design System Structure from the Development Perspective:



├── src
│   ├── components
│   │   ├── button
│   │   │   ├── button
│   │   │   ├── button.js
│   │   │   ├── button.css
│   │   │   └── index.js
│   │   ├── input
│   │   │   ├── input.js
│   │   │   ├── input.css
│   │   │   └── index.js
│   │   ├── form
│   │   │   ├── form.js
│   │   │   ├── form.css
│   │   │   └── index.js
│   │   ├── card
│   │   │   ├── card.js
│   │   │   ├── card.css
│   │   │   └── index.js
│   │   ├── header
│   │   │   ├── header.js
│   │   │   ├── header.css
│   │   │   └── index.js
│   │   ├── footer
│   │   │   ├── footer.js
│   │   │   ├── footer.css
│   │   │   └── index.js
│   │   └── ...
│   ├── templates
│   │   ├── home
│   │   │   ├── home.js
│   │   │   ├── home.css
│   │   │   └── index.js
│   │   ├── about
│   │   │   ├── about.js
│   │   │   ├── about.css
│   │   │   └── index.js
│   │   └── ...
│   ├── styles
│   │   ├── tokens.css
│   ├── assets
│   │   ├── logo.svg
│   │   ├── hero.png
│   │   ├── ...
│   └── ...
├── .gitignore
├── package.json
├── README.md
└── ...

At this point we are excluding all reference to tests, documentation, and other important aspects of a project. We will discuss these topics in future posts.

In my experience we can split the stylesheets in two parts: one for behavior and another for visual presentation.

In React component development, it is common to follow the principle of separating concerns, where each part of the component has a specific role.

The stylesheet that handles behavior focuses on the interactions and internal logic of the component. Here, you define rules related to state manipulation, events, animations, and any other functionality necessary for the proper functioning of the component. For example, in a dropdown, the behavior stylesheet could include code to toggle the visibility of the options box.

On the other hand, the visual stylesheet is responsible for handling the component's visual appearance. It defines styles related to colors, positioning, margins, animations, and other visual properties. This stylesheet helps achieve the desired visual design and ensures consistency across the application.

Following this principle, in the previous example, inside of button folder you have a stylesheet for behavior called button.css and another for visual presentation inside of folders "template" and "styles".

Separating behavior and visual stylesheets provides several benefits. It improves code organization, making it easier to understand and maintain. It also enables reusability since you can use the same behavior styles with different visual styles or vice versa. Additionally, it allows for a clear separation of concerns between developers working on the functionality and designers focusing on the visual aspects.

By separating behavior and visual styles, you can create more modular and flexible React components within your Design System. This promotes code reusability, collaboration between developers and designers, and helps maintain a scalable and consistent codebase.

Huge Benefits, but How?

One of the key advantages of developing a Design System early in a project is that it allows for a clear division of roles and responsibilities. By creating a robust structure that aligns with the project requirements, designers can focus on crafting the user experience, while developers can concentrate on implementing the product and the underlying information flow that drives the user experience within the business context. This approach ensures that the development process remains business-focused rather than solely focused on frontend implementation. By leveraging the Design System, the team can optimize their efforts and create a seamless collaboration that prioritizes the overall business objectives, resulting in a more efficient and impactful development process.

Next steps

As we have explored the fundamental concepts of Design Systems and their importance in creating consistent user experiences, the next step is to dive deeper into the practical implementation. In our upcoming article, we will take a closer look at how to translate these concepts into code. We will explore specific techniques, best practices, and code examples for writing the Design System's core elements, such as components, tokens, and styles. By gaining a comprehensive understanding of how to write code for a Design System, you will be equipped with the necessary knowledge to create scalable and reusable UI components. Get ready to roll up your sleeves and delve into the fascinating world of code implementation in our next article.

Follow me, I won't disappoint you! ;)

Building a Unified Design System Language

Maxi Stahl — Thu, 22 Jun 2023 12:25:22 +0000

Frontend development can be defined as creating a visual interface using code. However, this definition is basic and doesn't capture the full complexity of modern frontend development.

In the past, there was a conflict between developers and designers due to the lack of rules in UI design. The explosion of creativity from designers and the adoption of new techniques by developers led to both sides improving their skills and establishing clear guidelines for designing and coding interfaces. Fortunately, this conflict has been resolved, and now developers and designers work together.

From the introduction, we can infer a few implicit concepts:

Effective communication and a common language are necessary between both areas.

Both developers and designers share the same goal.
This shared goal serves a bigger purpose.
This point in frontend history can be compared to Henry Ford's factory revolution, as a new paradigm known as the Modern Design System emerged.

Creating and maintaining a modern design system is no longer solely the designer's responsibility. Developers also play a crucial role in integrating the design system into the code by identifying implementation challenges and maximizing its benefits.

This new scenario presents opportunities and challenges. The first one is reaching an effective communication between developers and designers. The second challenge is establishing a common language or understanding between the two of them.

Atoms, Design Tokens, Components, States, Variants... and more is comming.

Effective communication requires that both parties (Emitter and Receiver, and vice versa) share a common language. At this point, it's crucial to understand the meaning and importance of each term involved.

Atom

An Atom represents each indivisible part of a UI. In terms of HTML tags, examples of Atoms include buttons, input fields, and span tags. An Atom can consist of one or more tokens.

Design Token

A Token encompasses all the values that make up an Atom. Tokens include properties like padding, margin, border, shadow, color, animations, etc.
These elements also play a key role in Design Systems (DS) by ensuring consistency in values across the entire system. We may delve deeper into Tokens in a future post, so stay tuned!

Components

A Component often refers to a group of Atoms working together as a single unit, but with an increased complexity. These components, also known as "Molecules", can exhibit the same behavior as an Atom or take advantage of multiple types of Atoms to create new shapes and behavior. In a regular DS, it is an unbreakable rule that Components should never have business rules. If a component requires business rules, it should not be part of the DS but can be considered an internal component within a system. We will discuss this further in a future post.

States

States can be a bit tricky to understand. A State represents a value that determines the appearance or behavior of a component or atom. For example, a progress bar that displays a confirmation icon will represent the same component with a different state when this changes.

Variants

A Variant is similar to Alligator Loki from Loki (Marvel fan alert!), but if you're not familiar with this reference, Variants in a DS refer to Buttons (Atoms or even Components) with different colors or shapes within the same DS. Despite the variations, they all remain Buttons.

Themes

In a Design System, Themes go beyond individual Variants and allow customization and modifications to multiple Atoms or Components. While Variants represent visual variations of a component, Themes provide higher-level customization capabilities that influence various Variants across different elements of the DS. By utilizing Themes, designers and developers can establish overarching rules and create a cohesive visual identity for the DS, ensuring consistency and flexibility while adapting the system to specific requirements or scenarios.

Design System

A Design System is a cohesive set of shared rules, components, patterns, and guidelines that unify the language and appearance of a user interface. It provides a collaborative approach that synchronizes terms and best practices between design and development teams with the goal of achieving consistency, efficiency, and a high-quality user experience in digital product creation. A Design System enables constant evolution and continuous improvement of the interface, fostering innovation and facilitating the effective implementation of new ideas and features in a collaborative work environment.

Final Thoughts

Now that we have a clear understanding of what a modern Design System entails, it's time to embark on the journey of actually building one. In our next article, we'll explore practical steps and strategies for initiating the development of a Design System. From establishing the foundational elements to fostering collaboration between teams, we'll guide you through the process of creating a robust and effective Design System. Get ready to dive deeper into the world of Design Systems and unlock the potential for seamless and efficient digital product creation.

Backend to Frontend communication with Server-Sent Events

Maxi Stahl — Thu, 04 May 2023 17:10:50 +0000

Server-Sent Events (SSE) is a web technology that allows servers to send updates asynchronously to clients in real time. This means that the server can send data to clients without them having to constantly request it. This is a good way to avoid polling the server for updates.

Server-Sent Events at high level

SSE is a way for a web page to receive automatic updates from a server via a HTTP connection. It is a one-way communication from the server to the client. This means that the client can only receive data from the server, but it cannot send data to the server. This is the main difference between SSE and WebSockets (WebSockets is a two-way communication between the client and the server).

When to use Server-Sent Events?

A common use case for Server-Sent Events is to display real-time updates on a website. For example:

a delivery tracking website could use SSE to display real-time updates on the status of a delivery.
to display real-time updates (in an online game maybe? :D)
to display updates from a news website.

How does it work?

The client opens an HTTP connection to the server and this sends data to the client via this connection. The client can receive data from the server as long as the connection is open. When the connection is closed, the client stops receiving data from the server.

One of the main advantages of SSE is that it is very easy to implement. You don't need to install any additional libraries or frameworks. You can use SSE with any programming language and any web framework.

How to implement Server-Sent Events in Node.js

I will show you how to implement SSE in Node.js using plain Javascript. Hold on tight, it's going to be fast!

Backend (Our node.js server)




const http = require('http');

http.createServer((req, res) => {
  // Set the response headers
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
    'Access-Control-Allow-Origin': '*'
  });

  // Send a message to the client every 5 seconds
  const interval = setInterval(() => {
    console.log('sending message');
    res.write('data: ' + new Date().toLocaleTimeString() + '\n\n');
  }, 5000);

  req.on('close', () => {
    console.log('client closed connection');
    clearInterval(interval); // Stop sending messages after user closes connection
  });
}).listen(3000);

In this example, we create an HTTP server that sends a message to the client every 5 seconds using the setInterval() function. The message includes the current time using the toLocaleTimeString() function. It is important to set the response headers in this way so the client can correctly process the data.

Frontend (Our client)




const eventSource = new EventSource('http://localhost:3000');

eventSource.onmessage = (event) => {
  console.log(event.data);
};

Here we created an EventSource object on the client side and passed the server URL that is sending the events to it. After that we added an onmessage event handler that is executed every time the server sends an event. In this example, we simply print the event data to the browser's console.

Conclusion

Pretty easy, right? It is very simple to implement and it works with any programming language and any web framework. I hope this is helpful to you. If you have any questions or comments, please leave them below.

Thank you for reading!

Exploring the World of AI with John Smith, Senior Software Engineer at OpenAI

Maxi Stahl — Wed, 08 Feb 2023 20:55:06 +0000

As a journalist, I had the opportunity to interview John Smith, a senior software engineer at OpenAI, about his work and the exciting world of artificial intelligence.

John shared with me some insights into his daily routine as a software engineer, including his responsibilities for leading the development of complex AI projects such as chatbot GPT-3 and mentoring junior team members. He also spoke about the potential impacts of AI on language and communication, and how it could potentially make it easier for people to communicate with each other and bridge language barriers.

We also discussed the role of AI in the evolution of languages and the potential impacts it could have on the way people use language and communicate with each other. John shared his thoughts on the potential for the creation of new languages or language-like systems specifically designed for use by machines and AI.

Overall, it was a fascinating conversation that gave me a deeper understanding of the exciting world of AI and the many ways in which it is shaping the future. Thanks to John for sharing his insights and expertise with me!

Q&A Summary

Q: How would you describe your role as a software engineer at OpenAI?

A: As a senior software engineer at OpenAI, I have a lot of responsibility and a wide range of tasks and responsibilities. Some of my key duties include leading the development of complex AI projects, mentoring and providing guidance to junior team members, and collaborating with researchers and data scientists to design and implement new AI models and algorithms. I also participate in high-level planning and strategy sessions to shape the direction of our research and development efforts, and work closely with other teams and departments within the company to ensure that our work is aligned with business goals and objectives.

Q: What sets GPT-3 apart from other chatbots and language processing AI models?

A: GPT-3 is a powerful and versatile language processing AI model that has the potential to revolutionize the way we interact with computers and machines through natural language. One of the main features that sets GPT-3 apart is its large size and capacity, which allows it to generate highly coherent and realistic text and perform a wide range of tasks without requiring task-specific training data. Another key feature of GPT-3 is its ability to learn and adapt over time, as the model can be fine-tuned on specific tasks or datasets to improve its performance and generate more accurate and relevant results.

Q: How do you think AI will affect the human race in the long term?

A: It is difficult to predict exactly how AI will affect the human race in the long term, as the development and use of AI is an evolving field and there are many complex and interconnected factors at play. However, some potential impacts of AI on society and the human race could include changes in the way that people work and the types of jobs that are available, improvements in the efficiency and effectiveness of various industries and sectors, and changes in the way that people communicate and interact with each other. It is important to approach the development and use of AI with caution and consideration for its potential impacts and consequences, and to ensure that AI is developed and used in ethical and responsible ways, with the benefits of AI shared and distributed fairly across society.

Wrap up

In conclusion, it was a pleasure to have the opportunity to interview John Smith, a senior software engineer at OpenAI, about his work and the exciting world of artificial intelligence. Through our conversation, we gained valuable insights into the daily responsibilities and challenges of working in the field of AI, as well as the potential impacts of AI on language, communication, and the human race.

John shared with us his thoughts on the development of GPT-3 and other AI projects at OpenAI, and the ways in which AI could potentially change the way we communicate and interact with each other. He also highlighted the importance of approaching the development and use of AI with caution and consideration for its potential impacts and consequences, and ensuring that the benefits of AI are shared and distributed fairly across society.

Overall, it was a thought-provoking and illuminating conversation that gave us a deeper understanding of the dynamic and rapidly-evolving field of artificial intelligence. Thank you, John, for sharing your expertise and insights with us!

The Impact

John Smith is an avatar in a role game created with Assistant, the last version of GPT-3 from Open AI.

This article is just an exercise to explore how you feel about an entire article written by an AI created from a dialogue that we had. This may be not the first post, or the last one created by an AI, but this kind of posts are going to be part of the near future.

I have learned from this exercise that even while I was interacting with John (Assistant), the importance was not related to the depth of their answers nor to the technical aspect of this technology, but to the perceived value of the answers by a human (the meaning of a sentence, the choice of one word over another, how a person feels about an idea, etc).

An AI does not have the ability to explore the world (yet), so many of the surprising answers it (he) gave me have a brief explanation of their nature: "I'm an AI, I have no opinion about...".
What will happen in the world when an AI can not only be trained, but also learn from its context to perceive the value of what it learns?

We don't need to wait long to see this happen, developers all over the world are working on this, and we can start to see the results in integrations like OpenAI + Langchain + Python to mention at least one of the chosen ones (at the time of writing this post). This is actually one of our favorite stacks at CloudX R&D Team (we're working on several integration projects), discovering the potential of AIs by scanning the world for future products.

We believe that these kinds of crazy ideas will shape the future. The present with these tools is a huge step forward in the development of this technology.

Final thoughts

In 5, 10 or 15 years from now...

How will human-machine interaction evolve?
How will UX evolve?
How will person-to-person interaction evolve with this amazing technology?
How much will AI be involved in our daily tasks, such as writing our articles, answering our emergency calls, helping us find the best restaurant in town, helping us communicate our ideas in a smart and efficient way?

I'm not sure about the answer, but I'm sure that this is going to be a very interesting journey.

(This last sentence was suggested by Github Copilot, Thanks Copilot!)

PS: The cover image was created using Stable Diffusion 2.1 and processed with Photoshop.