Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts about the chat UI #493

Closed
schiessle opened this issue Nov 21, 2017 · 13 comments
Closed

Thoughts about the chat UI #493

schiessle opened this issue Nov 21, 2017 · 13 comments

Comments

@schiessle
Copy link
Member

I just tried the latest version of the chat and it works really good! 😃

During test I found some visual stuff which I think could be improved.

This is how the chat window looks for a guest:

talk1

I think the icon of the current user should be next to the input field, not above. I saw that for a logged in user we show the user name next to the icon but for the guest user the name is on the top, quite confusing. Also on top the "copy icon", the user name and the "join call" button looks a bit randomly listed and squeezed together.

A general note about the chat window: I would put the input field on the bottom and scroll the messages from the bottom to the top, like most messengers does.

This is the chat window for a logged in user:

talk2

I was a bit confused that at the top I read "You". It looks like it is related to me as a user. Maybe my current display name for the chat? Only after changing it I realized that it is the room name.

Further I don't think we need to have the user name next to the avatar, instead I would just put the avatar left to the input field. We could show the user name on hover if we want to.

Same as on the public page also here the text/input fields at the top looks like randomly put next to each other. I think we should add some structure there.

cc @nextcloud/designers

@danxuliu
Copy link
Member

I think the icon of the current user should be next to the input field, not above. I saw that for a logged in user we show the user name next to the icon but for the guest user the name is on the top, quite confusing.

The icon and the name are shown in the same place both for guests and for normal users. The problem in your screenshot is that the guest has no name set, so the space to the right of the icon is empty. Setting a name would not change anything, though, as there are still some problems with guest avatars and names that need to be solved :-P But if it worked as planned the name of the guest, or a placeholder like Name not set yet, would appear next to the avatar.

I would put the input field on the bottom and scroll the messages from the bottom to the top, like most messengers does.

The reason to put the input field on top and show messages from newest to oldest was for consistency with the Comments app.

Besides that, something to be taken into account is that the list of chat messages shares vertical space with the room info. When showing the messages from newest to oldest you can just show the full list of chat messages; if the user is more interested in the chat than the room info she can just scroll a bit to see only the chat view with the latest messages.

However, when showing the messages from oldest to newest you can not show the full list of chat messages; otherwise you may need to scroll back pages (and there would not be Home and End keys on a touch screen) if you need to see the room info or the other tabs. Therefore, when showing the messages from oldest to newest you must provide a scroll bar only for the list of chat messages, and keep the room name and tab headers in place.

On large screens that may be fine (even if you lose some space for the chat messages), but for smaller screens you could be left with a space too constrained for the chat messages (and for the first version there will be no mobile clients for the chat, so it would have to be accessed using the Web UI in smaller screens).

A solution could be to automatically hide the room info and tab headers and show them back when scrolling up (think on the URL address bar in mobile browsers). In fact I have been already working on that, but it is trickier than it seems, and I feel that I have been spending too much time for too little gain...

Anyway, although right now the chat view is shown only in the right sidebar the idea is to show it in the main view when the user has not joined the call and only move it to the right sidebar during calls.

When shown in the main view there is no longer the problem of sharing vertical space with other elements, so the chat view could be shown there in the usual way, that is, input field on the bottom and messages from oldest to newest.

But then, if the chat view in the sidebar was kept like it is now, the chat view in the main view and the chat view in the right sidebar would be inconsistent. The chat view could be shown with the input field on top and with messages from newest to oldest in the main view too, but I think that it would be a strange layout in that case.

Thoughts on all this?

I was a bit confused that at the top I read "You". It looks like it is related to me as a user. Maybe my current display name for the chat? Only after changing it I realized that it is the room name.

This is a general issue of Nextcloud Talk, not only chat-related. We should either provide a better default name for rooms or make clearer in the sidebar what is the room name. Any idea?

Further I don't think we need to have the user name next to the avatar, instead I would just put the avatar left to the input field. We could show the user name on hover if we want to.

I prefer to always see the user name :-P

Same as on the public page also here the text/input fields at the top looks like randomly put next to each other. I think we should add some structure there.

Again, a general issue of Nextcloud Talk. And yes, the room info needs some design love ;-)

@danxuliu
Copy link
Member

A solution could be to automatically hide the room info and tab headers and show them back when scrolling up (think on the URL address bar in mobile browsers).

Well, I have realized that there is a way simpler solution: provide a button to expand the chat view to use the full sidebar, and to go back to its original size when clicked again.

@jancborchardt
Copy link
Member

One solution for the "No guest name shown" would be to move the guest name from the top to the chat view directly next to the avatar where guests could edit it.

@nickvergessen nickvergessen added this to the 3.1 (Nextcloud 13.0.2/3) milestone Nov 27, 2017
@schiessle
Copy link
Member Author

One solution for the "No guest name shown" would be to move the guest name from the top to the chat view directly next to the avatar where guests could edit it.

Another idea I discussed with @Ivansss these days:
Most of the time you don't need to see your name. Think about other chat apps, there you also don't see your name all the time. We could show the name only if you hover over your profile picture, next to the name a small pan, if you click you get a input field to change your name.

@danxuliu
Copy link
Member

I have realized that there is a way simpler solution: provide a button to expand the chat view to use the full sidebar, and to go back to its original size when clicked again.

Done in #558

@jancborchardt
Copy link
Member

@danxuliu as commented in that PR, this is a quite confusing solution from the UX point of view. I would rather go with the consolidation and simplification of elements so the room details always have and low height, as done in More design work & clean up to reduce possible height of room details #562

@danxuliu
Copy link
Member

@jancborchardt

I would rather go with the consolidation and simplification of elements so the room details always have and low height, as done in More design work & clean up to reduce possible height of room details #562

I am afraid that this is not enough. For large screens? Sure. For small screens it does not matter how much you reduce the height of room details. See (OK, the password field will go away and there will be more room... but still not enough in my opinion):

talk-sidebar-small

I still prefer the button to expand the view, which I do not see confusing at all, by the way; why is it more confusing that switching the video to full screen mode?

@jancborchardt
Copy link
Member

jancborchardt commented Jan 10, 2018

@danxuliu

(The »I would like to be able to maximize it« is not a user story ;) it’s a feature request disguised as one.)

@danxuliu
Copy link
Member

If the whole area is scrollable – how we usually handle it and how the design is intended –

If the whole area (I guess you refer to the sidebar) is scrollable I either see the new messages or the call info. Which is fine... until I want to see the other one and then I have to scroll the whole sidebar. Or what am I missing?

there would be plenty of room. We could have the tabs stick to the top, including a simple scroll-to-top handle.

Yes, we could have. But right now we do not have it. What we have now is a sidebar not very usable in small screens.

There’s more whitepace above the room name and above the tabs I can look into.

There is only so much whitespace that can be removed ;-)

(The »I would like to be able to maximize it« is not a user story ;) it’s a feature request disguised as one.)

You can call it however you like :-P The thing is that I, and with I I really mean I, @danxuliu, would like to be able to maximize the sidebar contents. And as far as I know I am a user too, am I not? ;-)

I would still like #558 to be merged, at least for 3.0. It can be easily removed for 3.1 once those issues you mentioned are solved, but until they are solved the sidebar is almost useless in small screens. I prefer a confusing UI (which I do not see as confusing at all, I would still like to know the answer to why is it more confusing that switching the video to full screen mode? ;-) ) than a useless one ;-)

@jancborchardt
Copy link
Member

Right, of course only the content needs to be scrollable cause chat is now reversed. My mistake.

3.0 is already done, and for 3.1 I'd rather continue properly. Adding that floating fullscreen icon in the middle there has its issues as you can also see from @nickvergessen's comment.
And the issue that you can only see either the chat or the details is only made worse by that approach.

So really, having the call info/header design properly done like with #562 is the way to go here.

(And yes, all of us are users too, but very technical ones. And technical people are not our core audience. :)

@danxuliu
Copy link
Member

And the issue that you can only see either the chat or the details is only made worse by that approach.

No, you can see the details and the chat, or just the chat. Which in my opinion is perfectly fine. During a call I do not expect to have the need to check how the room is called, nor to share the link with someone else not in the call, nor to set a password for it. Those fields are just filling up precious space that would be better used for other things that I may be more interested in, like the chat messages. And that is up to the user, nobody is forcing her to see only the chat. If she is fine with both the details and the chat she can see both (and that is even the default).

Anyway it is clear that I am not going to convince you that having the option to maximize the chat in the sidebar in small screens is good, and you are not going to convince me that always showing both the room details and the chat in the sidebar in small screens is good. I give up :-P

But, again, I am still waiting for the answer to why is expanding the chat more confusing than switching the video to full screen mode?. And I am not asking it to annoy you, seriously; I am actually curious about that.

@nickvergessen
Copy link
Member

But, again, I am still waiting for the answer to why is expanding the chat more confusing than switching the video to full screen mode?.

I think the only thing that is confusing is the button in the UI.

I would even go ahead and for fullscreen automatically switch the chat to the active tab and fullscreen it too.

@jancborchardt
Copy link
Member

I’m closing this in favor of #499 which has more specific action points in it: #499

If there’s more, please open separate issues about the individual enhancements, as a big thread will always derail. :)

marcoambrosini pushed a commit that referenced this issue Oct 9, 2019
Bump url-loader from 2.0.1 to 2.1.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants