Chat re-design

[mmbotelho]

Problem

We need to make our chat match the rest of the app!

Solution

What needs to be designed:

• [x] (Flow) Create a new channel
• [ ] Settings of each channel
  • [x] Rename channel
  • [x] Add description
  • [x] Edit description
  • [x] See member list
  • [x] Add members (for private channels only)
  • [x] Remove members (private channels only)
  • [ ] Mute / Unmute channel
  • [x] Delete a channel
  • [x] Leave channel
• [x] Automated messages:
  • [x] Channel name was changed;
  • [x] Channel description was changed;
  • [x] A member was added the channel;
  • [x] A member left the channel;
  • [x] New proposal open
  • [x] Proposal closed (accepted)
  • [x] Proposal closed (denied)
  • [x] Proposal closed (expired)
  • [x] A channel was deleted
  • [x] Someone voted on a poll
• [x] Actions on each message:
  • [x] React to a message
  • [x] Edit a message
  • [x] Delete a message
  • [x] Copy message link
  • [x] Link to a specific message
  • [x] Mention members in a message
  • [x] Reply to a message
• [x] Link previews
• [x] No link preview available
• [x] Start a private conversation
• [x] Add emojis to the message input
• [x] Adding polls to the chat
  • [x] Create a poll
  • [x] Vote on a poll
  • [x] Change your vote
  • [x] See who voted
  • [x] See results
  • [x] Automatic message when someone votes on the poll
  • [x] Edit poll
• [x] Empty states for channels and private conversations
• [x] How does it look when you have a new message:
  • [x] On a channel;
  • [x] On a DM;
• [ ] Message members external to your group.
• [ ] Let users know if members are online
• [x] See if someone's typing.

Iteration tasks: This is a set of tasks that came up after the first draft of the chat functionality - mainly through suggestions on Figma:

• [x] Ability to dismiss a link preview;
• [x] See who reacted to messages;
• [x] Undo action of adding members to private channel; I will be updating this thread as I get these boxes ticked, and let me know if you think there's anything missing (or if there's any functionality we can remove for the prototype).

[mmbotelho]

I have an idea of what the general layout of the chat should look like, here's a preview:

Figma link

Here's the rationale behind some of the decisions:

Left-most sidedbar

• I used a sidebar on the left-side of the screen for 2 reasons:
  • To keep the layout consistent across the app;
  • I used the same approach as Facebook. Why? Because facebook, unlike Slack or Discord, is also a platform that has a chat but that's not its focus - similar to Group Income.
• I removed the group shortcuts - It is important that the group-swapping is done by clicking on the left-hand group switcher. If we enforce this path, users will learn it more easily.
• The right-hand sidebar needs to be scrollable;

Channels

• A general channel is automatically created for all groups, and all members are automatically added to the group;
• When a new public channel is added, everyone is automatically added;
• When a private channel is added, the creator needs to specify who should be added. After the group is created, any member in the group can add more members to the channel

The feedback I need at this stage:

• What do you feel about the general layout?

Keep in mind that this is a draft and not all the UX issues are solved at this stage. However, please leave a comment with any concerns or suggestions on Figma, as usual!

[taoeffect]

@mmbotelho I think this general layout works quite well, and some little details still need to be thought about and added. Off the top of my head I can think of:

• UI for linking to a specific message
• UI for editing messages
• UI for reacting to a message
• UI for editing a channel's settings (including notifications, privacy, etc.)
• Shrinking the spacing/font of the message content area a bit so that more messages are visible and less scrolling is required

Per your suggestion, I can add additional feedback on Figma, and/or copy/paste this feedback there.

[mmbotelho]

I added what you mentioned to the checklist above (I'm not sure if you saw it) but some of the details you mentioned were already listed there 😄

I just have one question, about the "UI for linking to a specific message" - can you explain better what you mean by this @taoeffect ?

[taoeffect]

I just have one question, about the "UI for linking to a specific message" - can you explain better what you mean by this @taoeffect ?

Sure, this is related to an already existing issue: #509 — Improve URL-based navigation

The basic idea is that we should strive to make as many "things"/"components" in the UI linkable, so that if for whatever reason we want to be able to send the user to some part of the app, we can — either programmatically because we want to show them something, or because the user themselves wants to show someone else something.

In this case, imagine someone posts an interesting message to the chat and that message gets pushed up in the history. It could be instructions on how to use git to review PRs for example. Then 1 month later someone wants to send those instructions to a new member of the group. The easiest way for them to do this would be to search for that message, grab a link to it, and send that link directly to the person they want to share it with.

The UI would then load that specific message when the other person clicks on it.

[mmbotelho]

Ok that makes sense!

I have on more related question @taoeffect - do we have any idea how we will manage the storage of these chat conversations? Will everything be stored or do we need to have some sort of mechanism to archive or delete old messages so we don't run out of space?

[taoeffect]

That's a great question. Regarding storage, we will have:

• "archival nodes" / "full nodes" — this is the appifyed version of the app (not the in-browser version), with maybe a checkbox checked, that stores every single thing that happens in the group. Most users will not be using this version.
• The server — the server acts as its own archival node
• Most users will not be running archival nodes, instead they will be running the light clients (#691), and to dig into old message archives they will have to query the server for info. Implementing search will certainly be interesting when messages are end-to-end encrypted, and not stored locally.

All of this will require a good amount of work to implement correctly.

[mmbotelho]

So, from the users perspective:

• After a certain number of messages is reached, old messages are archived as new messages come in;
• Users can still access these archived messages, but not by scrolling up like they normally would - they would have to do some other action in order to find those older messages (like the search you mentioned);

Is this correct @taoeffect ?

[taoeffect]

@mmbotelho I don't think so... scrolling up should work fine. It should just load the historical messages from the server.

However, in practice there might be limits to this because of unforeseen technological limits placed on us by browsers. So in some cases an error might be displayed if you scroll too far, or in some cases scrolling will work without any problems. Assume for now that it works (or might not work) and that we'll handle both cases accordingly.

[mmbotelho]

Ok, so no visible changes for the user, right? Except maybe some sort of loading

[taoeffect]

Right. And a "be flexible because we don't know exactly how this will work out" kind of mindset. :D

[mmbotelho]

Ok, no worries!

[sandrina-p]

In my opinion, we should keep the chat as simple as possible and within the "time budget". The way I see this thread, we are trying to replicate all the features that major chat apps have. In my opinion, that's a trap...

For example, "Channels" features are designed for huge groups with a large set of topics to talk about. GI groups are way smaller. Do we really need to have channels for the prototype? Especially when most groups will have ~5-10 members? (My guess, I can be wrong.)

I think some features are not essential (and the development cost can be high). We can add them later, but not as part of the prototype. For example:

• Adding the option to create a poll in a channel
• Adding proposals to the chat (?)
• Reacting to a message.
• Edit a message.
• Add members / remove members (for private channels only)
• Private messages. - This can be a little extreme, but I really think that a single chat room per group is enough for the prototype. This can be added after the prototype though.

Remember, GI current goal is not to be a "AAA quality" chat application. The chat is just a way to help the group members reach their income. Trying to replicate a "AAA" chat in such an early stage is a mistake in my opinion. What will make GI unique is the "mincome system". In my opinion, everything else is secondary to the prototype.

P.S. We cannot forget/ignore that probably a good chunk of the groups will prefer to keep their "communication channel" outside of GI (e.g. Telegram, Whatsapp, etc...) too.

[taoeffect]

@sandrina-p I agree that we should limit the functionality for the prototype.

However, I also think that many of these features should be designed — just not implemented.

If we were to do the opposite, and design a simple UI without channels, without public/private channels, etc., then we would have to spend a lot of $ unnecessarily in asking Margarida to redesign everything.

I do not like that approach, because it is costly not just in terms of limited funding but also in terms of time. I'd much rather get a flexible, powerful design from the outset, and limit its functionality in the implementation (e.g. with "Feature coming soon!" type notices).

---

@mmbotelho I just remembered something from prior conversations that appears lost in this design.

It is really really important that we create a design for the chat functionality that allows cross-group communication. I.e. please put some though into how members of Group A can still chat with members of Group B. I know that Slack recently introduced such a feature for their channels.

Additionally, you should be able to DM anyone whose full username you know (e.g. @userA@groupB.com.

[mmbotelho]

I agree with @sandrina-p as well. However, I'm ok with designing everything even if we don't implement it.

@taoeffect :

It is really really important that we create a design for the chat functionality that allows cross-group communication. I.e. please put some though into how members of Group A can still chat with members of Group B. I know that Slack recently introduced such a feature for their channels.

If you don't mind, I'll leave that for last. If you remember, we already discussed some possible solutions for this in Bulgaria. Anyway, I'll add it to the list.

Just to add to what @sandrina-p said, I think this (very complex chat) is a deviation of what GI wants to be. Do we want it to be an excellent fund re-distributor or an excellent chat? Doing both WELL, at the same time, is just not feasible so I think we should really focus our efforts here.

If we want to make an awesome chat that works really well, I believe it should be its own, separate project, that can be plugged into GI.

But anyway, that's my 2 cents. I'm ok with whatever you decide @taoeffect , but I do think it's important that we share our concerns with you.

[taoeffect]

If you don't mind, I'll leave that for last. If you remember, we already discussed some possible solutions for this in Bulgaria. Anyway, I'll add it to the list.

Sure, it would just be a shame if we ended up facilitating the creation of closed-nit cults. Although a remote possibility, I'd still rather make sure that users can use the app to communicate with whoever they want, not just those inside their group.

Do we want it to be an excellent fund re-distributor or an excellent chat? Doing both WELL, at the same time, is just not feasible so I think we should really focus our efforts here.

I understand that it seems like we would be increasing the scope too far.

We have already done a great job on implementing an excellent redistribution app, haven't we? Almost everything for that part is done.

It's well known that in order for people to put in the energy to migrate from System A to System B, there has to be enough of an incentive for them to do so. Sometimes that incentive has to be at least a 10x improvement.

Think about why people moved from flip phones to the iPhone. The iPhone was not just a better phone. It was not one new product. When Steve introduced it he made a big point of pointing out that they were not introducing a single new product, but 3 new products all at once. This was a necessary step, because had they introduced simply a better phone, people would not have migrated from the flip phones to it.

There is another reason to make sure we do a great job at chat: as I've spoken with people about Group Income, they have had concerns about how they will know about what's going on in the group with respect to financial changes. We are not building just a redistribution app, we are building an app to power communities. Such an app needs powerful chat functionality.

[mmbotelho]

Update on the emoji selector for our chat:

I spoke to @sandrina-p about possible solutions that are fast to implement and design for our emoji picker (and that work across different platforms). She suggested this option and from what I've seen, it looks exactly like what we need.

I would also suggest that we use the Apple-style emojis for all devices so that all members see the same emojis (to prevent misunderstandings).

[sandrina-p]

@taoeffect, maybe I should have been more clear. My main concern is the development part, not the design.

We have already done a great job on implementing an excellent redistribution app, haven't we? Almost everything for that part is done.

I disagree. There is still a lot to do. The redistribution is still very buggy, as well as the "decentralized system" where contracts get out of sync for weird reasons. And we still need to implement the Notifications system before moving to the chat. And "implementing" something is only half of the job. The other half is seeing real users using the app and approve it. Only then we can say we actually did something excellent.

Let's be pragmatic. We are just 3 developers in part-time. Doing an "excellent redistribution app" and closing the +50 "Priority:High" open issues will take time. Adding the "complex chat" feature will delay even more the prototype.

If you really want to do it @taoeffect, I'm okay. You are the one who takes the final decision and the team will follow.

We are all aware of how important/needed GI is, as a "mincome redistribution" app. Let's remember that each time we take the decision to sacrifice its prototype release (by delaying it) for an additional feature.

---

Regarding the emoji selector, what I suggested is meant to be used with React but there's also a VueJS based option.

[taoeffect]

@sandrina-p Maybe there was a misunderstanding somewhere, because I agree with everything you've said. I do not intend to delay the prototype because of the chat. Once the core functionality of the app is functional (all those issues you pointed out), then we will go ahead and release it, whether or not the chat stuff is done. Remember, the prototype and the 1.0 official release are two different things.

I am just saying that while I happen to be in recovery from overwork or an illness, and while we are looking to fill this position, we may as well move forward with both the Chat design and the chat implementation since the other stuff requires waiting on me to fully recover. Does that make sense? Let me know if you still disagree!

[sandrina-p]

That makes sense, I thought your plan was to release the chat as part of the prototype. I misunderstood it.

[taoeffect]

Just making a note here per @mmbotelho's suggestion on Figma, so that I don't forget what was discussed on today's call: for DM's between people who are not in a group, we will leave that for the to-be-designed Lobby.