Design pattern: DECK of CARDS
Tags: ui, ux, design, webde
Published: 2024-04-29 21:48:54

## We're talking about managment-type web-apps.

The standard is a structure with **menu** and a **master/detail pattern**
There are many examples: G-Mail, Slack, Linear and others
However, I have often found structural limits when faced with this pattern

## A new pattern: DECK-of-CARDS

![Biblio](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7votkvv98b3gxg43930u.png)`old work that used the DECK-of-CARDS pattern`

Generally the forms are developed vertically
and the monitors offer more than enough width.
The idea is to line up the **form details** next to each other like a deck of cards and eliminate the **"master"**.

![cards](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d7q4kr3vyllak4g2z83g.png)

Of course, this approach has challenges (I talk about them at the end).
I implement this pattern in a very recent work that you find here:

[NUI (demo)](https://demo.natsnui.app/)
[GitHub](https://github.com/nats-nui/nui)

The first thing you see is a card on a work surface!
This represents a **list of connections**
We don't care what it is: let's just focus on the UI/UX.

By clicking on a **connections** in the *list* another card appears
represents a single **connection**.
Click on the seed of the card (lightning bolt at the top) and you can open it
and you can drag it from the title... basically that's all!

![connections](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k9fl0fi4hha214cscrvb.gif)

the **connection card** has properties (name, host, auth) and contains other cards that it can "generate"

![connection](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2a5fuvmiwp8o9q4tumif.png)

For example:
by pressing on **streams** the **streams list card** appears
and continuing to press on a line we obtain the **stream** detail card and so on.
The cards can be detached from their **parent-card** and rearranged as you see fit.

## Use cases and possibilities:

### Compare two different details with each other.

![diff](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1apc8doevodsc1mm02cq.gif)

I detach a card from its **parent** and I can generate another one side by side, making it easier to identify differences and relationships between the data. For example to compare two JSON.

### Have a value that is always visible regardless of what you are doing.

![pro2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4mx7byz43qclhctygzzs.png)

While continuing to manage **messages**
I can always see the values present in the **stream detail card**.
For example, it could facilitate the work of a financial analyst who compares market data.

### Easily locate items that would otherwise be hidden by the MANU/MASTER/DETAIL structure

![desk](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wilwe0dcpo6rsytagwx3.png)

I moved the "interesting" cards into the "drawer" so I could use them at any time.

![pin](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q9kq3rrute72y5mzbda0.png)

Since the cards are "atomic" I can **pin them** on the menu and recall them individually at any time

### Personalized work environment
I can **arrange** my **deck of cards** in order to have an overall view.
This **arrangement** can be stored in session and will be my usual **work-space**.
Also I could have different **work-spaces** to manage different projects.

### Sharing individual information
I could share (via link) a single card
in order to give precise and limited information to that area.

### Global search
With this layout it is easy to implement a search/filter that only shows the important cards.

### Realtime simultaneous work
Potentially having all the CARDS visible on my **work-space**
I could "invite" collaborators to see or modify the cards.
This would not be possible with a classic **MASTER/DETAIL** pattern.

### Global stocks
For example: print, destroy, send, export...
It's easy to imagine moving a card into a bin or onto a printer and so on.
These actions would be intuitive and applicable to any entity
without having to implement them for every **detail**.

### Modular development
You just need to render your card correctly from creation to destruction.
But you can go further! You could load cards into your app from an external repository developed by others

### Automate processes
Set up an action flow, for example:
"If a message arrives in this **messages-card**
then write it to a file (**file-system-card**) and display the **streams-card**".
That is, connect the cards to nodes with a graph scheme to automate these functions.

### Challenges and possible solutions

### Onboarding
Since it is a new pattern, the average user does not know how to interact "instinctively".
In fact, I would not recommend it for an occasional service such as an institutional site or a product.
However, if the user is expert and requires a fair level of complexity there are certainly notable advantages!
A solution could be the classic "tutorial" that appears on the first visit.

### BACK/FOWARD buttons
the MASTER/DETAIL, using routing, has no problems with this.
For DECK-OF-CARDS it is necessary to implement a history of the positions of the cards
which is absolutely possible but more complex to achieve.

---

That's all.
I look forward to reading comments and any criticisms
I recommend delicacy! :)
CIAO!