Pending contacts out of popup

[jpt]

I realize this mockup is introducing a lot more than the title lets on, but figured this issue is as good a place to start as any regarding UI/UX.

A popup window for a pending contact request isn't ideal for users, especially if multiple requests start adding up. I'm suggesting a collapsable list. I think if Ricochet forced "Use single window for conversations" there might be a few opportunities to improve the overall user experience, which I'll start addressing in other issues.

[timkuijsten]

I think if Ricochet forced "Use single window for conversations" there might be a few opportunities to improve the overall user experience

I think this is the default since 1.1.4. #355

[jpt]

@timkuijsten To be clear, I am recommending removing the option entirely.

I haven't thought much about how to name the contact after accepting (maybe once you click the green checkbox, the contact name becomes a blinking cursor input field with grey "Contact name" placeholder text before the user starts typing?), but here's what I imagine the rest looking like:

On clicking the "paoi45io5u34ipj" contact name under "Requests", the contact name is underlined on the left once selected, and the user is presented with the initial message from their contact as part of a normal conversation. Selection doesn't have to be an underline, could be something else like a bubble around the name with a dark background and inverted text.

To accept the request and begin conversation, the user has the option of clicking a checkbox right next to the name in the "Requests" list (i.e. where their cursor already is after clicking the contact name). If the "Use single window" option remains, then there can be an additional contact checkbox next to the contact name in conversation at top right.

Perhaps if the the user tries typing a message before explicitly accepting the contact, a red line could appear beneath the checkbox to remind the user of its necessity, and if the user tries a second time, that line can bounce to catch their attention. Or maybe the input field could additionally be disabled with an overlay asking to accept or reject the contact -- still thinking about that. That is the default behavior, though? No contacting the other user until you accept? Or should typing a message and hitting return be interpreted as "accept"?

On clicking either of the green checkboxes, the checkboxes disappear, and the contact name moves from the "Requests" list to the "Contacts" list.

[jpt]

Perhaps if the the user tries typing a message before explicitly accepting the contact, a red line could appear beneath the checkbox to remind the user of its necessity, and if the user tries a second time, that line can bounce to catch their attention. Or maybe the input field could additionally be disabled with an overlay asking to accept or reject the contact -- still thinking about that.

After thinking about it, I am leaning toward not having these underlines/reminders and instead getting straight to the point with a modal popup. If the user replies to a request message before actually checking the box to accept the request, they can be presented with the option of either accepting the request & sending, or canceling. Given Ricochet's threat model maybe this confirmation of first contact is worthwhile.

[timkuijsten]

If the user replies to a request message before actually checking the box to accept the request

What about showing the modal as soon as the user ticks the input field, but before he/she starts typing the message?

[jpt]

@timkuijsten I think I like that behavior better, good idea! That prevents wasted input and I can imagine an edge case where it mitigates risk for the kind of user who is eager to type their message and maybe clicks "Accept" without thinking about it.

[timkuijsten]

Idd, I think it lowers the urge to "send anyway" if the message itself is not typed yet.

[special]

You are a fantastic person, @jpt.

I'll have some more thoughts in a moment, but the quick responses:

I think if Ricochet forced "Use single window for conversations" there might be a few opportunities to improve the overall user experience, which I'll start addressing in other issues.

@timkuijsten To be clear, I am recommending removing the option entirely.

I agree. Consider it done, unless someone wants to mount a really compelling defense.

After thinking about it, I am leaning toward not having these underlines/reminders and instead getting straight to the point with a modal popup. [...] Given Ricochet's threat model maybe this confirmation of first contact is worthwhile.

What about showing the modal as soon as the user ticks the input field, but before he/she starts typing the message?

Yep. I was about to say that the reminders seemed a little too subtle, and accepting implicitly would be worrying. This seems like a good approach.

I haven't thought much about how to name the contact after accepting (maybe once you click the green checkbox, the contact name becomes a blinking cursor input field with grey "Contact name" placeholder text before the user starts typing?), but here's what I imagine the rest looking like:

This is important to get right. I agree with using the address as a default name if we have nothing better, but people should almost always name their contacts. It's too easy to get confused otherwise. This suggestion sounds worth trying.

Technically, you can send a name for yourself along with a contact request, but the current UI doesn't expose it. I'd like most or all requests to have a name provided by the sender eventually. This is a little tricky, because those names are completely untrusted. I'm not sure how they should be presented.

[special]

[Contact list] selection doesn't have to be an underline, could be something else like a bubble around the name with a dark background and inverted text.

I prefer a bubble. The underline is subtle, and I'd like to strongly reinforce and repeat which contact messages are being sent to. Accidentally sending a message to the wrong contact is a critical failure.

I agree with putting Requests at the top of the list; they're usually something you want to react to immediately. If there are more than 3-5, we should collapse the rest into a " + 4 more", or just stop acknowledging them and force peers to try again later. The UX and implications of being flooded with contact requests is a whole different set of problems, I guess.

I like putting the request message in conversation style, but it's not clear that a person can't send you any further messages until you accept their request. How about putting a banner under their message in the conversation, with some text prompting you to accept the request and the accept/cancel buttons? Any other ideas?

I'll take my comments on other parts of the UI to other threads, but this is looking really good. Thank you!

[jpt]

Maybe plus/minus symbols for expand/collapse?

Still considering naming.

(The white background blur is repeated where the Add Contact and Settings buttons are.. you just can't see it because there's nothing down there. Eventually, at the top of the contacts list, users might benefit from an input for search, but that can probably wait for now.)

[jpt]

And here that is, slightly modified and with an expanded view