Bringing two worlds together

Teamcom UI exploration (Desktop)

In the following I want to present UI explorations for our upcoming app Teamcom. For this case I used OS X as the base platform. Mobile and web UI would be updated accordingly.

What is the core of the product? 
Teamcom wants to be your all in one team collaboration and communication platform. It’s based on threaded conversations known from emails and combines one-on-one and team direct messages. On top of that it will have a deep integration with our to-do list app, Todoist.

Bringing two worlds together
In Each “world” has different use cases and requirements. That’s why most apps try to concentrate on doing one thing at a time in the easiest and most efficient way. Especially on mobile because of the limited space of smartphone screens. Some examples: Slack is great in live, direct messaging with a group of people or privately. Gmail is great in presenting and organizing your emails. Though, almost every communication and social media platform incorporates direct messages. Facebook offers DMs in a separate tab which loads a new UI focused on DMs; as well as a small chat window on the bottom right screen that always stays visible. Gmail or Inbox by gmail do the same. The focus is on emails but you can also open your hangouts chats. Notice the different UI of for example facebook posts and the chat window or emails and the hangouts chat.

Chat in facebook
Google Hangouts directly in gmail
Some of Facebook’s different comment/post input designs. Chat popup, DM, Post (top to bottom)

Facebook uses more than one input design for posts and chats. Each taylored for each use case. Chat popup: Fast text input, sending via “Enter”, DM comment box in the direct messages window focused only on DMs. Choose between “Enter” or “Reply” button. Lastly the Post, which obviously shouldn’t post something directly via enter. The user should carefully craft her status update and post it. This is more sensible information that will be shared with more than one person, mostly publicly.

The same goes for emails and Teamcom threads. Our model contains “recipients” like email and a message will mostly be shared with multiple people. It’s important that the comment box doesn’t look like chat. We need buttons to confirm to send something. I won’t go into details of the comment box in this post. This is another big challenge that has to be solved.

Referring to Teamcom, you see, the use cases for “threads” and “DMs” in Teamcom are very different and require a slightly different UI. Please keep this in mind when looking at the following UI prototypes. A unified inbox could be burden in this regard.

TC Nav 1 and 1.1

Chats and DMs in top/ bottom tabs:

Pros and cons:
+ focus on one “app”
+ Threads and DM UI can be different w/ different input types
+ usage like two separate apps
+ inbox only for threads

– discoverability of tabs and difficult navigation? Limited space = limited tabs
– “Inbox” can be confusing, what does it include?
– “Starred” can only be used for threads, not DMs
– Search UI can be confusing: it’s first level and w/ extra tab in threads; what can you search in DMs? only people, messages? Extra search tab needed?

TC Nav 1
TC Nav 1.1

TC Nav 2

Threads meet slack

Pros and cons:
+ channels and users directly visible, including online/offline status
+ one click away to contact someone
+ unified inbox
+ “back” button in messages would get you back to a thread right where you left off
+ easy search: threads and DMs have the same design

– users/group DMs on the left menu are listed unnecessarily twice to keep the 3 pane layout
– hard to tell DMs and threads apart in inbox
– comment box design can’t be easily optimized for both use cases

TC Nav 2

TC Nav 3

Messages a tab away

Pros and cons:
+ 3 pane layout stays. messages are seemlessly integrated in the layout
+ search can be universal
+ additional search bar for only contacts

– users not directly visible in a glance, only when “Messages” is opened
– you can’t see “is typing…” for DMs when in a thread or inbox
– focus on channels and threads, because always visible

TC Nav 3

TC Nav 4

The hybrid layout

Pros and cons:
+ good overview: channels and users directly visible, including online/offline status
+ unified inbox
+ “back” button in messages would get you back to a thread right where you left off

– layout gets broken from 3 to 2 panes
– different threads and DMs comments UI and comment boxes could look strange in the unified inbox

TC Nav 4

TC Nav 5

Side panel

Pros and cons:
+ keeping an overview. focus on one “app” at a time
+ Threads and DM UI can be different w/ different input types
+ easy switching and adding of workspaces/accounts like twitter or slack
+ unreads directly visible on the side panel
+ side panel can be extended with more “apps/sections”: files, calendar, todoist?

– layout gets broken from 3 to 2 panes
– confusing search UI?
– switching between two apps: confusing: where should I post what?

TC All-in-one

Concept that includes threaded, direct messaging and tasks

Pro and cons:
+ powerful all in one solution like Outlook: no need to change apps
+ focus on just one “app” and workflow
+ karma for all apps

– discoverability
– shortcuts possible in one app? how does quick add for task work?

+– unified notifications?

TC All-in-One Concept

Unified inbox

Some thoughts on the Unified inbox

Overview: https://www.dropbox.com/sh/t0i5lasmaxertz7/AACC5LgAaa3on7wPXA4CXfBua?dl=0

Inbox 1

To keep the overall UI clean and search results consistently displayed this Inbox #1 is the first logical design. Problem: You can’t tell DMs apart from threads that easily. But do you have to? Do we go with a different DM UI for comments and a different comment composer?

Inbox 1

Inbox 2 & 2.1

Inbox 2

The hybrid inbox includes “emails” and “messages” like email and a classic messenger app. I like the separation of the two, but your inbox could look absolutely messy if you have threads and DMs mixed up! The big avatars don’t let you star DMs. So, caution here.

Inbox 2

Inbox 2.1

Smaller avatars for DMs let you star and show unreads, but are too similar to the comments section. Works, but looks very repetitive in the UI

Inbox 2.1

Inbox 3

Inspiration from Inbox by gmail.

The system collects different threads for different topics and display them unified with an icon next to it; same in Gmail. Here is a solution where we have “avatars” for threads as well. Big problem: In normal channel views we can’t show these channel avatars. It would be too much unnecessary visual noise.

The UI of a unified inbox should ideally look very similar to normal thread lists in a channel, just with a minor additon of an type indicator: an update from a specific channel or a new DM.

As mentioned above the unified inbox brings more problems than it solves. So lets try to separate DMs from threads strictly.


Activity and notifications

Some ideas

The only valuable information that we can collect in a “notifications” stream is:

  1. Showing reactions: John and 5 others reacted to your comment.
  2. Being added/removed from a channel

Without making the “activity” feed a place where the user has to manage stuff, like seeing comments, or duplicated information that overwhelms. The activity feed would be universal, so you would see reactions from threads, as well as from direct messages. Messages are already “notifications” itself, that you have to check, manage, comment and work on.

Activity/Notifications feed

Managing channels

Never lose information, stay up-to-date

We asked some of our colleagues who use the product about the usage of the “Inbox”. Many people use “Inbox”, known from email apps, that collects all unread threads like a timeline. Some users access unreads by going directly to each channel one by one. So why not offer the possibility to edit your menu and pick “favorites”? This way you can customize your channel list by your individual preference.

Sorting and filtering:
Why?
Customize your feed by information that fits you, find threads more easily. Sort by “recently seen”, “Alphabetical” or “latest activity”.

Sorting and filtering

Here’s a prototype that shows the basic navigation (bottom tabs):


Files

Some thoughts: Not sure if we will have a “Files” tab. Idea behind this was to display all files that have been shared in all channels that you are a part of. Have them accessible in one view and filter them by everyone/just you and file type. But given the possible huge amount of information, we might reconsider ditching this and just let the user find files in a “Search” view OR place a “Files” cell in the “More” tab.

Files tab

The communication structure

Lets start simple: We communicate in channels and direct messages. Here’s the structure:

A workspace contains channels, which contain different threads and we use a recipients model like email.

Direct Messages use a one-to-one/one-to-group conversations with a direct messaging model.

Comments on mobile

In threads and Direct Messages

On mobile channels and DMs are clearly separated in two tabs, which gives us the freedom to show a different UI, if needed.

On Todoist we have something similar. Personal and shared projects. In personal projects you create comments without recipients, in shared projects you can select recipients that are part of a project. As you can see, the UI is barely changed and is based on the stock messages input of iOS and well known UI conventions.

direct vs recipients model

Todoist isn’t only a communication app, but Teamcom is. So the emphasis on comments is bigger.

To get things started and keep the conventions one possibility would be to use the same comment input designs on both platforms (building a Product family).

Same interface, but different UX?

Different UI needed?

The following points are generally looking the same but behave differently. It’s important to have in mind if we need to change UI, so the user isn’t confused when switching from a thread to a DM conversation!

  1. Adding someone to a channel vs. adding someone to a group DM
    Both views show a list of users, but behave differently. When you’re a part of a channel you can be selected as recipient for a thread
  2. Users in a thread vs. users in a group DM
    The first message of a thread contains recipients. These recipients are added to the “Everyone in thread” group. When a new comment will be sent with new recipients, these are added to the thread, but don’t get automatically every message.
    A group DM needs users, which will be added to it. Here everyone gets automatically notified for a new comment.
  3. Creating “groups” in channels vs. creating “group DMs”:
    Naming confusing? Should we automatically create group DMs of groups that are created for thread recipients in channels?
  4. Notifying users via selecting recipients in channels vs. automatically notifying users in DMs
    In threads you select recipients, in DMs everyone gets automatically notified by a new comment. “Do not disturb” mode could be useful in the latter.
  5. Reactions in channels vs. getting reactions in DMs
    If we want to gather a unified “activity/notifications” the UI and interaction of and for reactions should be the same in each comment view.
  6. Visualizing attachments in channels vs. visualizing attachments in DMs
    If we have a unified search in one app, attachments should probably render the same in channels and DMs. Otherwise search results could look weird or we would need a dedicated search for each use case.

Some first design ideas for comments on mobile. 1–1 and group DMs. Imagine we are “Lovelyn Summers”:

Approaches:

  • Almost the same UI for channels and DM comments
  • Custom DM design