Single post view

The list of posts is apparently a feature every social posting application need. In this lesson, we'll work on a single post component.

The challenges we have

There are a few things we need to consider:

First, there should be a post-standalone component.
The component may have different variations and states.
It should be responsive.

So this is how posts look right now.

A common problem when designing a card that represents a complicated entity is that most parts of it usually have predictable dimensions. For instance, elements such as actions (edit, delete), dates, social networks, attachments, and pipelines typically have predictable dimensions.

To be precise, in cards, there are several types of content "units":

Fixed-size content. Buttons with fixed labels will always occupy the same space. Date/time labels almost always have the same size as well.
Unknown-sized content. A good example is attachments (mostly images/videos). You don't know exactly how many images a post might have.
Different types of text, usually a heading and some kind of description.

When we design a card, it's important to keep in mind that static elements should not occupy space in such a way that when other units (which don't have a fixed size) become bigger, the fixed elements create a big hole in the card.

It's easier to illustrate. If the content area grows, empty space grows as well, which is a waste of space and simply doesn't look right.

Of course you can limit the size of the content area, but it looks more like a hacky solution. Cards, which represent posts in our case, are almost identical to table rows. In the original design, there are labels above them.

But if a table row grows vertically, placing data that always takes up a small amount of height is not the best idea.

This is actually a universal principle. Say you have an entity (I'm using technical jargon on purpose). It has 10 attributes, a few actions, one image, etc.

If you display each attribute in the table as a separate column, the whole row's height will depend on the variable attribute.

This is a very common situation. And here is the key idea you should remember.

Try to move elements that have a fixed or predictable maximum width to the top or bottom of the card. In the case of tables, nobody restricts you from combining fixed-sized data and variable data in the same cell.

In the image below, we have some elements that have a predictable size (marked blue) and one element with unpredictable, possibly long content. The principle remains the same regardless of whether the element is a card or a table row.

By moving static (fixed-sized/predictable) elements on top or bottom, we fix the ugly empty space, and what's more important, the solution becomes more scalable.

Why so? The content area can be customized to any desired size. You can and should restrict it to some length. In our case, some posts may have one sentence, while others may have a large article.

Plus, when you realize you need to make it responsive, in practice you get some flexibility. You can hide some elements that are not necessary, display them differently, or, most commonly, just turn everything into one-column layout.

Back to posts

If we take a look once again at our current design, we'll see the gaps.

So far I've been talking about the visual part only. Now consider what should be displayed, its possible values, and how to do it. Here is a real list of posts that I got from the CEO.

Note the first row where I highlighted the status.

Let's go over what we may have:

Status

There might be at least three statuses: draft, scheduled, and sent. The key thing is that it has a predictable length. It is something that the system sets itself, not a user input.

I want to emphasize that the database status name has nothing to do with what users see. They might or might not be the same. Moreover, it's a common case when users filter a list of items by one status, while in fact the API filters by a combination of statuses.

There are many ways to display statuses, starting from a simple label and ending with a colored badge or something similar.

From personal experience

It's quite a common situation when you have a lot of statuses in the database, but users don't need them all.

For example, I had a project with an entity called "Document". The document had many statuses because it should be signed by many people, can be declined or accepted, and so on.

But what users needed was to see what documents were in the process of signing, namely, "in progress.". In the database, it might have been "signed_by_department_x" or "forwarded_to_department_y".

But in the filters, they were all united under one name: "in progress".

Date and Time

Date and time is a string with a highly predictable width. As well as status, it's an attribute that takes a lot of vertical space and breaks the card view.

Accounts

Accounts are less predictable. A user can have one account or many accounts. However, we can handle these cases differently. First of all, quite often users have only a few accounts. But sometimes there can be a lot of them.

Instead of outputting 20-30 avatars, let's stop for a moment and think about how users with such a huge number of accounts use them. Even though it's a hypothesis, I doubt that this is primary information that they pay attention to after the post has been scheduled or published.

I mean, once you added 20-30 accounts and scheduled a post for them, how often do you need to check which accounts the post will go to? Probably not that often. But still, there should be an option to show the list of accounts.

So how to solve the following dilemma: sometimes it can be a single avatar, sometimes 30+?

When you have a list of items whose number may vary, but they shouldn't draw users attention because there are more important things (in our case, the content of a post), you can limit the maximum number of items.

If the number is bigger, you can use the "show more" technique.

However, let's keep it simple for now. Since having many accounts is a rare case, for now we can move them to the next line. Later, we will iterate over our components.

Images

Showing images in the post card doesn't bring a lot of benefits if they are very mall. Although, it's debatable, since users can faster recognize what the post is about by looking at thumbnails, despite their small size.

But images are closer to non-fixed size fields. One image compared to four images might take a significant amount of space. Plus, we can attach videos and some other formats, e.g., PDF files.

Taking all this into account, it'd be better to show the number of attachments and reveal them on a click event.

Pipeline

A pipeline is like a queue. It's a simple string, usually short, so we can make use of "..." if it exceeds some limit.

A new look

Now we can come up with a new design of a single post. What do we already know?

Actions

Any actions like buttons are fixed-size elements. Also, it's a good practice to label your icons when possible.

Date

The date is also a fixed-size element. However, depending on the post status, it will mean different things. For example, a post can be a draft, scheduled, or already posted.

What we can do here is write a proper text, e.g., Scheduled on Friday, January 11, 8:29 PM, which already implies that the post is scheduled. This way we can kill two birds with one stone: display data and status together.

Avatars

Managing a large number of avatars can be a little bit tricky. For now, I suggest keeping it simple so that we don't get overwhelmed.

Pipeline

A post may or may not belong to a pipeline, which is usually a short string and an associated color.

Attachments

we might have attachments. These attachments can take various forms, such as images, videos, or even PDFs, which can be attached in LinkedIn.

At first I came up with the following design.

A few days later, I looked at it and found a few things that could be improved.

A second view

First of all, I added the Post Now button. This feature didn't exist in the original version, but I found it useful because users might want to publish a draft right now, and there is probably no way to do it other than changing the posting time.

But visually the button seems too large. Its height is 36px.

The minimum size for interactive elements should be at least 24x24 according to WCAG AA

We have some room to make the button less prominent and maybe even change its style. Also, it's probably better to put it close to other actions.

The second thing I overlooked was the font colors. Some were pure black, and some were shades of gray. We should be consistent even if it's a matter of a shade of gray.

The next thing that bothered me was the footer, which had attachments, a pipeline, and an indicator if the post is a thread. The thing is that for every social network, the post can be customized.

For example, I may have a picture attached to Twitter's post, and the post itself might be a thread, while on LinkedIn it might be a single post without a picture.

This makes things insanely complicated. However, I know that posts can have attachments and be in a pipeline on some social networks but not others.

To simplify things, I will remove the thread's indicator and attachments but keep the pipeline.

For sure we can improve the postcard further. For now, let's leave it as is since we'll fix all mistakes as we go through the course.

Next Lesson