Chat editor

POP 2016

At POP chat conversations power the platform. Every feature revolves around it and therefore conversations should be easy to create, edit and save. Just like Microsoft Word or any notepad app, POP needed an editor: a chat-editor.

The goal was to design something simple and familiar without losing the ability to create advanced conversations such as surveys, quizzes, chat forms and more.

Timeframe

September 2016 — Now

Role

Lead designer

Company

POP

Platforms

Web

When I joined POP there was no editor. I helped create the very first one (just an input field where you can enter 1 chat message) in true MVP style.

The platforms clientele was exclusive social media managers for music artists. To allow for more creativity than just 1 simple text message, we started designing and building our first editor.

The compose screen to send a message to fans.

These are some of the principles that came up in early discussions. At the time competitors had noodle-based user interface. Where you would create blocks of content and you had to connect them together (often with lines or arrows). Sometimes for very simple promotions the converstaions seemed overwhelming in the editor.

It must be straightforward and easy to create a simple conversation.

Follow the ‘top to bottom’ principle of a regular chat. The first message is at the top of the chat, the last one at the bottom.

Advanced features are important, but secondary in our editor.

An early prototype of the editor experience.

An early prototype of the most advanced conversation we could think of (as a campaign): quizzes. Correct answers should continue the conversation and wrong answers should bring you back. Without having to rewrite questions.

A still of a prototype where a 'block of conversation' is embedded in another conversation.

A view of a conversation showcasing merchandise in gallery cards.

This first version of the editor supported 3 different components used in Facebook Messenger): text, quick replies (buttons that appear underneath text messages) and gallery cards (larger cards with image, title, subtitle and button). It was designed in the same style of our dashboard to match the look of chat apps at the time.

A view of a conversation showcasing results after asking a multiple choice question.

This first version the editor however was only available on 1 particular page. Along with a refreshed design of our dashboard, the decision was made to make the editor available on all pages, via a pop-up like behaviour similar to common email apps.

This way any page in POP could launch the editor for a quick edit, save and continue your way flow. A good (architectural) decision that still works very well today.

A video demonstration of the chat editor in action.

More recently I have made different explorations as to how the editor could evolve and solve the issues with it.

We definded the issues as such:

  1. We are not saving on the ‘editor level’ but only on ‘component level’. This causes users to feel like they can make a change and discard it, but in fact we always save a change.
  2. Certain components have grown in the amount of features or options they provide to the user. This causes both UX and technical issues where the pop-over to edit those options becomes very large.
  3. It is possible to write a conversation in the wrong way and having to delete your work and start over. This is also due to certain restrictions that limit the user in the ability to re-order components.
  4. A growing number of components.
  5. A lack of help in the editor.

However, before I started on any of the details, I wanted to be sure the team/company was still set on continueing the current style of editor. To communicate the pros/cons of every different editor I printed out editors used by products such as Notion, Gmail, Manychat, Dropbox Paper, Medium, Wordpress Gutenberg.

A big argument for the type of editor chosen is that is really adheres to the principle defined above: to be simple first, advanced second. Plus some editors really wouldn’t work on tablets or mobile devices. That was something we did not want to rule out at this stage.

Google Docs

Wordpress Gutenberg

Outline

Notion

Dropbox Paper

Microsoft Word

To tackle each one of the issues I started sketching very early on. When encountering these issues in the past I had continually made notes of them and sometimes discussed them with engineers as they popped up. The list was not foreign to me when I started this project and that helped a lot.

1.
We are not saving on the ‘editor level’ but only on ‘component level’. This causes users to feel like they can make a change and discard it, but in fact we always save a change.

This issue is easy to adjust with design. A more obvious ‘save changes’ button up top along with version history (in a future iteration) would make the mental model of our customers match the editor.

A prototype highlighting some actions in the editor. By clicking on 'last edited by you just now' a user can enter the version history.

Displaying 'Save as...' under 'More' as an option alongside a prominent 'Publish changes' button.

A detail from the version history indicator.

2.
Certain components have grown in the amount of features or options they provide to the user. This causes both UX and technical issues where the pop-over to edit those options becomes very large.

To combat each component displaying generic options to update a user's subscription, segmentation or other data, a solution could be to provide 1 'data update' component that would be invisible to the end-user in chat, but would handle all data updates.

Another bonus would be that in the editor itself, it is now obvious where data is being changed. Rather than it being hidden in certain components that also serve a visible in-chat function.

And instead of opening an enormous popover, the editor could expand like an accordion to make room for the component’s options and settings.

This image highlights the problem: even a simple quick reply button that is commonly used has a lot of functionality.

A generic, non-visible in-chat component to serve all data updates.

Instead of opening a popover, the properties and settings of a component could open in an accordion style to not overlap other components.

A protoytpe highlighting the experience in the editor of opening the data update component. For prototype purposes this data component opens with 1 property already selected.

3.
It is possible to write a conversation in the wrong way and having to delete your work and start over. This is also due to certain restrictions that limit the user in the ability to re-order components.

Reordering components was a true puzzle when we first got to introducing components with restrictions. For instance, the quick replies component must always have at least 1 message in front of it. You can not start a conversation with it.

This creates al lot of cases to handle in the editor:

  1. You can’t re-order the 1 message in front of it to another position.
  2. You can’t delete the 1 message in front of it.
  3. You can’t start the conversation with quick replies.
  4. Re-ordering quick replies is not straightforward, you can’t just move it anywhere.

Due to these restrictions, it was sometimes possible to write a conversation in the wrong way, realize this, and then decide it was better to write it all over again.

Because the restrictions are set, a possible solution to make the editing process smoother could be to be able to ‘group’ the messages in blocks, and then ‘explode’ that block again. This way you can move larger pieces of conversation around, without the limitations.

A view illustrating the issue and structure.

Improved hover states for components to indicate the re-ordering possbilities.

A prototype of the various hover states on components and the ability to select, group and ungroup multiple messages.

4.
A growing number of components.

The growing numbers of components is mostly fixed by re-ordering and merging functionality across components. For instance almost all of our components allow a user to be added to a specific segment (a group of people), it would be easier to create 1 component for adding people to segments instead of duplicating the feature for every component. A simple improvement.

The issue: too many components to choose from.

A prototype of the new picker in it's basic form.

An idea where on hover you see a small preview of the component you're about to choose.

In the situation where the component library would grow, search could be introduced.

5.
A lack of help in the editor.

Even though the editor has to be as intuitive as possible, it will always have people not fully understanding it’s functionality and experience bugs. Therefore it should be easy to find help in the most advanced section of the product, without leaving the editor.

To make help always visible, in the bottom right corner a small question mark is displayed at all times. This opens the help sidebar and from there, resources and help is just a click away.

A prototype of an easily accessible sidebar to provide help.

Some mockups to present and showcase the editor with members of the team. Along with in-person talks I shared various prototypes in Slack to get other people’s perspective and thoughts too.

A mockup highlighting various states of the editor user interface.

A mockup showing the creation of a conversation screen.

A mockup showing the mobile editor user interface.

A mockup showing the editor with multiple messages.

The editor has proven to be a very fundamental feature of POP and I’m happy it’s foundation is still solid and working well.

I’m also proud of the process the engineers and I went through to provide valuable improvements to real problems customers face. Though we haven’t been able to ship everything, the ideas here are a really good evolution of the editor.

3

Foundational design principles for the chat editor

15

Different components in the chat editor (and growing)

100+

Iterations, additions and changes to the original chat editor

Projects

Prototyping for car user experience design

Graduation project Hike One 2016

Dashboard and workspaces

POP 2019

Inbox

POP 2019

Design system

POP 2016

Chat editor

POP 2016

VISA app

Work in progress Personal project 2020

Contributions

Feedback and design suggestions for Coronamelder

Dutch corona app 2020

Experience

Thank you for visiting this piece of internet. Reach me at hey@lucvanloon.com or find me on Dribbble, , LinkedIn.

Press M to unmute audio