Implement new "talk to a person" UI

[ara4n]

Filing this as a design-tagged issue to differentiate from the existing #1392 and friends.

The result of talking to @antikewl this morning about having clear separate first-class citizens for "talk to user" versus "join/create a room" was to discuss 3 options:

1. make the (+) button in the bottom left give the choice of 'are you adding a direct chat or a room' before proceeding. this was dismissed as the thing users are complaining about is the idea that you have to 'add' or 'create' anything when you start talking to a person. People exist already; you just want to talk to them.
2. make the (+) button take you to a modal "Start!" screen of some kind which has both "talk to peeople" and "join/create rooms" sections or tabs. Dismissed for same reason as the first option.
3. replace the current (+) and (directory) buttons with two new buttons: one for initiating direct chats; the other for joining/creating rooms. Thus creating new rooms could be seen as part of directory management (or perhaps vice versa). => Trevor to flesh this out.

Conclusion:

1. Switch icons on bottom-left menu for design (as per http://zpl.io/1BkPWb)
2. Add hoverover tooltip as per design for bottom-left menu icons (as per http://zpl.io/1BkPWb)
3. Implement new 'Start chat with a person' screen (as per http://zpl.io/23ggM9 and http://zpl.io/1iXBEQ and http://zpl.io/1VAP77). We do not need the "manage networks" or searching external networks for now, we can search the current user DB that vector's old invite code maintains.

We do not need the final screen (http://zpl.io/Z7mQSg) as far as I can see.

[antikewl]

Status update: Complete, BUT bottom left icons (rooms/new 1:1) need to be changed now that I’ve used the “add person” icon for the icon in the bottom right to invite someone to a room.
https://zpl.io/1BkPWb

[ara4n]

This looks very promising - thanks. I still think that the (+) icon for 'join/start a room' may need to somehow indicate rooms, rather than being a generic plus.

Something we have lost (and it seems to be my fault when writing up our conversation when I was in Rennes the other week) is the ability to locate who we are trying to talk to (or the room we are trying to join) based on remote network.

So, if I want to "speak to Trevor on ribot.slack.com", how do I tell the search thing that the 'trevor' i'm autocompleting should be looking for him on ribot.slack.com, rather than a different slack, or a different IRC network, or indeed Matrix proper? Likewise if I want to join "#general", how do I say that's on ribot.slack.com, rather than an IRC channel called #general on (say) Freenode?

Both finding people & rooms is going to need some way to specify the target network. For people, we also have the (existing) option of inviting by email address and giving them the option of how to join.

[antikewl]

Ah, ok. I think this is probably a sub-task of #1756. I'll add your comment there.

[ara4n]

The design here is good to go for the 'find people' screens as per:

• zpl.io/1BkPWb (and the next 4 screens, linked below for completness):
• zpl.io/23ggM9
• zpl.io/1iXBEQ <-- with the simplification of skipping remote networks until the contact lookup API is available.
• zpl.io/1VAP77
• zpl.io/Z7mQSg <-- I don't think this screen is actually needed, as per the comment on it.

The one proviso is that the 'room' icon still doesn't seem right, but this can be changed down the line.

The 'find room' screens are not finished or signed off yet, however.

[ara4n]

Plan is to split this into a People and a Room ticket so that @wmwragg can proceed on People unfettered.

[ara4n]

with #2054 split off, this is now signed off for real and good to go for @wmwragg

[wmwragg]

@ara4n Would you be able to update the description of this ticket with what it now represents, i.e. what I need to implement, cheers

[ara4n]

@wmwragg gah - sorry, missed this and got hijacked by other stuff. have updated the description now.

[ara4n]

have split out #2070 from this as discussed.

One issue that has come up however is what the behaviour should be if there are multiple 1:1 rooms already in existence to the target user. Options are:

1. We either select one to reuse at random
2. Always create new 1:1s
3. or prompt the user to select from the choice of existing rooms somehow (which requires more design for displaying that choice).

[ara4n]

Conclusion on the above from talking to @wmwragg today was to reuse the oldest one.

[ara4n]

Feedback from the #2181 PR:

• the overflow scrollbar on the RHS of the input field seems to be stuck on? Fixed
• ...likewise on the autocomplete selection Fixed
• the padding of the autocomplete doesn't match the design (compare the height of 3 rows between @antikewl's zeplin design and the implementation) On implementing, the design was changed (must have forgotten to update Zeplin), as the unequal spacing just looked weird, and didn't really work when scrolling up and down, so the current equal spacing was chosen instead
• the autocomplete doesn't take up the full width (but this may be deliberate? It is indeed, as per the design, it would look very overpowering if it was full width
• the entirety of the invite tile in MemberList should probably be a hit target. This was not done on purpose, as all other round icons behave as buttons, so when people see a round icon they know it behaves as a button when clicked, but if you start extending the hit targets for buttons (round icons) that link will be confused (even if you only do it for a couple of buttons)
• It would be really nice if tab completed manual mxids (as well as space and comma), given tab-complete is our common idiom here. I can do that but it would be weird UX, as I thought tabbing was used to tab-complete, and we're not doing that here, as they are manual mxids and emails no completion is happening. <return> is being used to select the mxid from the list of possibles, should this be <tab> instead? If so then <tab> to add a manual mxid/email would make more sense, but my understanding was that <return> was the correct use here
• Final question: is a deliberate design that the 'User ID, Name or email' prompt is always on the last line, rather than flowing inline and moving over the autocomplete bar to match? (superficially, removing the width of the textarea, setting display: inline-block and putting a relative offset on the autocomplete bar seems to work) Yes it was deliberate. When manually entering email addresses, and long mxids, it can be annoying to only see a small part the address you have entered, and having to scroll back to check you entered it correctly, have a play with Dropbox's share dialog, which is typical of this style

[wmwragg]

@ara4n I have updated the above points, please tick off the sections that you're happy with the explanation for, and ping me any you aren't

[ara4n]

Okay, the ones i'm not happy with are: hit target for 'invite user' tile. Given visually it's aligned with the rest of memberlist, i'd really really expect it to behave like the other tiles there, even if technically the round thing is a button rather than an avatar.

Tab-complete rather than Return-complete. In autocomplete (both pre- and post-RTE) in the editor, we use tab to mean "please complete the current suggestion and move on". We can keep return-to-complete too, but please can we have tab as well. thanks!

[wmwragg]

@ara4n OK will do

[ara4n]

closed - thanks! :D