Improving the UI Design of the Post Screen in a Social Media App

This article discusses the UI design improvements made to the post composition screen of DAWN, a Mastodon client for iOS.
DAWN aims to balance the usability of a native iOS app with Mastodon's nature as a decentralized social network.
Recently, the app was featured three times on the App Store and has received high praise from users.

In this update, we pursued a more native 'Liquid Glass' UI while organizing information and expanding functionality on the post screen. As features grow with continuous updates, UI tends to become cluttered like a toolbox. This improvement addresses that challenge, aiming for a design that allows users to interact intuitively.
This article summarizes the trial and error process from the legacy UI to the current design, as well as the underlying philosophy.

Post Screen UI Organization (2.0.33)

2.0.32	2.0.33

From version 2.0.33, we significantly overhauled the UI design of the post screen.

• Post-specific settings such as visibility and quote permissions have increased.
• The old UI was reaching its limits for information placement.
• We wanted to create an extensible structure, assuming further feature additions in the future.

---

Motivation

Mastodon 4.5.0 introduced 'Quote Permission' settings.

Meanwhile, the old UI occupied a large area for visibility settings, and there were concerns that adding more post settings would break the layout.

• We want to keep important information like visibility easy to see and change.
• However, we want to prevent the settings UI from occupying the top of the screen.

Resolving this imbalance was the starting point for this renovation.

---

Characteristics of the Old UI

Following the LiquidGlass UI, a large toolbar was placed above the keyboard.

• The editing tools were swipeable, providing high extensibility.
• Non-editing tools (like visibility) were grouped in the row above.
• While it looked rich, the priority of information was somewhat unclear.

---

Prototype 1: Moving Post Settings Outside the Toolbar

This was the first draft where visibility, quote permission, and language were moved outside the toolbar. Although information was better organized, the overall balance felt awkward. Another issue was that these elements easily overlapped with the body text during scrolling.
Since progress was slow when thinking alone, I shared this screenshot with matsuji-san to get feedback.

---

Feedback 1: Organizing Information Priority

I received the following feedback from matsuji-san:

• Consolidate warning text displays into the lower tool side.
• Character counts should be placed in a more prominent position.

This feedback confirmed that the balance of the upper toolbar was indeed poor, even from an objective perspective. Furthermore, the fact that moving the warning button to the bottom toolbar felt natural indicated that the categorization of the editing tools within the toolbar itself was not well-organized.

---

Reference 1: Observations from Comparing with Ivory

As I proceeded with the review, I realized that I had unintentionally moved closer to the design philosophy of Ivoly, the Mastodon app by tapbots.

At the same time, the following issues became apparent:

1. The language button is too prominent, yet users shouldn't need to be that conscious of language when creating a post.
2. Changing the visibility settings alters the character count, which shifts the position of the language button—it feels uncomfortable.
3. Placing elements outside the toolbar makes them prone to overlapping with body text during scrolling, necessitating visual clarity through background application.

I felt these were common challenges for DAWN and organized them as points to be resolved.

---

Feedback 2: Realizing the 'Nature' of @/# Buttons

After a while, matsuji-san shared a draft showing 'what it would look like if I built it from scratch'.

What's interesting about this proposal is that the @ and # buttons are placed independently above the keyboard.
Seeing this, I realized these buttons function more as 'keyboard auxiliary tools' rather than 'editing tools'.

Another major difference from the existing UI is that the send button is placed at the top right.
In the context of iOS design, placing the send button at the top right is natural, but I felt strongly about keeping it at the bottom for DAWN.

Although X also has the send button at the top, I decided to maintain our approach, believing that 'ease of sending' can be an identity for a third-party app.

The idea of consolidating other tools into a '+' button is a pattern adopted by the Messages app, and it is also reasonable from an extensibility perspective.

Honestly, I had considered a similar UI, but I thought the changes were too significant and perhaps unnecessary. However, reaching the same conclusion from an outsider's perspective made me feel that there might be some universal truth, and I proceeded to create the next prototype.

---

Prototype 2: Breaking Down into 3 Layers

Based on the feedback and references, I created a prototype UI. First, I reconsidered the tool grouping and categorized the editing-related elements into three groups:

1. Visibility
2. Editing Tools
3. Pseudo-Keyboard (Emojis, Hashtags, Mentions)

Visibility

Referencing the X app, I placed this discreetly above the body text.

This is a pattern many users are already accustomed to, making it easy to learn.

Editing Tools

Editing functions like media insertion were consolidated into the '+' button at the bottom left.

Pseudo-Keyboard

I separated emojis, hashtags, and mentions, giving them the same accessibility as keyboard keys.

At this point, since there was no place left for a character counter, I decided to try it without a 'character count display'.

I noticed that Mastodon has a relatively generous limit (e.g., 500 characters), so users don't necessarily have a hard time without a constant character display.

---

Reference 2: Visibility Button

For the appearance of the visibility button, I used X as a reference.

• X uses a button with a downward chevron.
• However, the meaning is sufficiently conveyed even without the chevron.

Therefore, DAWN uses a simple style without the chevron.

---

Brush-up 1: Aligning with Standard App Context

With the direction solidified in the prototype, I moved on to polishing the details.

Button Sizes and Spacing

I aligned button sizes and spacing above the keyboard with standard iOS apps like Safari.

Send Button

Changed the horizontally long button to a circular one. This is also to match native Apple apps.

Pseudo-Keyboard

Adjusted the button group to be left-aligned.

This was to reduce anxiety about accidental taps if the @ button were too close to the send button.

Visibility Button

Changed the label from 'Public' to 'Everyone'.

Similar to X, it provides a more concrete image of the visibility scope.

It also aims to soften the pressure conveyed by the word 'Public' (in Japanese).

---

Brush-up 2: Labeling and Concerns

By adding labels to the editing tools, the meaning of each function became easier to understand.

For media insertion and 'Now Playing', I displayed app icons following the Messages app.

On the other hand, the following concerns emerged:

1. The entire menu is somewhat large, making frequently used tools feel distant.
2. The warning button feels too prominent.
3. Image Playground and writing tools occupy a large area despite the lack of necessity to call them from there.

---

Brush-up 3: Organizing Menu Structure

Based on these concerns, I organized the menu structure.

1. Moved Image Playground and writing tools to a sub-menu.
2. Removed 'Warning' from the main menu and moved it to the 'Post Settings' menu (described later).
3. Created custom SFSymbols for polls and '#foxcute'.
4. Since the emoji icon was the same as Messages stickers, I changed it to a slightly different design.

---

Brush-up 4: Post Menu and Character Count Display

From here, I organized settings related to the post creation screen.

1. Added a post menu in the top right and moved several functions there.
2. Implemented the character count display as a toggleable function between 'current count' and 'remaining characters'.
3. 'Add Comment' is a rename of the former 'Warning' function, aiming to soften the impression in the menu.

---

Reference 3: Character Count in Pages

My approach to character count display is based on the word count display in the Pages app.

• It is not displayed permanently but can be referenced when needed.
• It prevents excessive information from appearing on the screen.

---

Brush-up 5: Catering to Both Beginners and Advanced Users

By default, the character count is hidden.

However, by tapping the character count area, users can choose how it is displayed.

• Usually, you can write without worrying about character counts.
• It is displayed automatically only when the remaining character count becomes low.

I believe this creates a low-stress UI for both beginners and advanced users.

---

Brush-up 6: Expansion of Post Option Screen

The 'Visibility Settings' that used to open when pressing the visibility button have been expanded into a 'Post Options' screen that handles all post metadata.

• Language settings are also consolidated into this screen.
• Designed to handle future 'quote scope' settings as well.

---

SFSymbols: Emoji Icon Design

Since standard SFSymbols were insufficient, I created some myself.

The emoji icon design follows the sticker expression in Messages but features a 'downward fold' to distinguish its meaning.

I think I managed to differentiate it: a large sticker feels like pressing it down with weight, while a small emoji feels like a light stick-on.

Being an emoji, I also created a version with eyes, but I abandoned it as it increased the pressure on the post creation screen.

Also, for the community tag 'Fox Cute', I increased the footprints to two, emphasizing 'leaving footprints in the community' and a sense of 'territory'.

The poll button adopts a thicker style, referencing Messages.

---

Recap: What Was Gained from This UI Overhaul

2.0.32	2.0.33

Through this UI adjustment, the post creation screen reached the following state:

• The post area can be used more broadly.
• While securing feature extensibility, new features were incorporated smoothly.
• The placement of each tool is categorized, making user behavior more predictable.

Compared to a configuration where all tools are placed directly, access to specific functions increased by a maximum of 2 taps.

However, it remains well within the accessibility range provided by general applications, and considering the clarity gained through categorization and overall screen perspective, I feel it is a well-balanced compromise.