Rethinking the Jangouts UI

[Ancor Gonzalez Sosa]

In the previous message I sent to this list (Sept. 29th, zero replies so far) I wrote I would like to see some movement in the UI redesign, not only aesthetic, but specially from usability point of view.

So let me do a second attempt to get some discussion started.

It's pretty obvious that usability has never been one of the main concerns in Jangouts development, but if we want to look into the future we need to pay that technical debt the sooner the better. The current approach to UI has become a limiting factor. Some examples:

 - It was requested to change the way to pin a participant [1]. It was implemented, but the result is far from optimal (I will elaborate in a separate mail with links to demos).
 - The underlying parts needed to make possible to change a participant's name [2] were also implemented, but we were not able to find a way to make it fit in the current UI
 - If somebody decides to implement per-user volume [3], they will have the same problem.
 - I also have in mind a "local mute" feature (see this comment [4]), but once again I wouldn't know where to place that button.
 - Screen sharing needs better handling. One possible approach suggested in [5].

Moreover, there are some usability problems we keep hitting all the time:

 - The button to mute yourself can move if somebody else (who is displayed before you) enters the room.

 - The name of the room is not displayed.

And there are even more design decisions that some people dislike despite being conscious decisions taken by the developers (like [6]).

Last but not least, the current UI kind of works in mobile devices, but it's not 100% mobile friendly (buttons are too small and it relies too much in buttons that are only revealed on hover).

I would like to be enlightened with a new approach for the Jangouts UI, solving as many mentioned problems as possible and flexible enough for the future. I know myself well enough to know such idea will not come out of my mind. I need help from more clever people.

I'm all ears (erm... eyes).

[1] https://github.com/jangouts/jangouts/issues/131

[2] https://github.com/jangouts/jangouts/issues/15

[3] https://github.com/jangouts/jangouts/issues/22

[4] https://github.com/jangouts/jangouts/issues/22#issuecomment-259167767

[5] https://github.com/jangouts/jangouts/issues/160

[6] https://github.com/jangouts/jangouts/issues/162

[Ancor Gonzalez Sosa]

First of all, sorry for the weird formatting on my previous mail. Credit goes to the web frontend of Google Groups ($DEITY bless the email clients).

El martes, 27 de diciembre de 2016, 13:26:01 (UTC+1), Ancor Gonzalez Sosa escribió:

[...]

 - It was requested to change the way to pin a participant [1]. It was implemented, but the result is far from optimal (I will elaborate in a separate mail with links to demos).

Let's elaborate

Here you can see the "classic" UI
https://jangouts.tk - The footer should read "Version 0.4.5beta". If not, use shift+reload

And here the UI change contributed to address [1]
https://jangouts.tk/ui2/ - The footer should read "Version 0.4.5b-ui2"

Some people like the new approach (ui2) more because it's more intuitive and probably even nicer.

But, as explained in the original mail, I'm worried about scalability (what if we need more buttons in a near future), about "discoverability" (if you don't know the feature is there, maybe you will never try clicking in a thumbnail), about cleanliness (relocating the remaining buttons makes the UI look crowded), about consistency (clicking the face pins the stream but clicking in the name doesn't) and about usability (having the "mute" button too close to other buttons like "ignore" looks like a problem to me). Not to mention the change reduces the size of useful nicknames.

Somebody suggested a set of changes to improve ui2:
  - Consider the face and name as a whole regarding hover
  - Keep the buttons in the current locations but showing "ignore" and "disable video" only on hover
  - Clicking while on hover (anywhere except in a button) makes the user sticky

I agree that would be better. If we all agree, I will make (ui2 + suggested_changes) the default in the upcoming 0.5 version.

But still, I would rather rethink the whole UI, as suggested originally in this thread.

Cheers.

[1] https://github.com/jangouts/jangouts/issues/131

[Ancor Gonzalez Sosa]

El martes, 27 de diciembre de 2016, 13:26:01 (UTC+1), Ancor Gonzalez Sosa escribió:

In the previous message I sent to this list (Sept. 29th, zero replies so far) I wrote I would like to see some movement in the UI redesign, not only aesthetic, but specially from usability point of view.

So let me do a second attempt to get some discussion started.

It's pretty obvious that usability has never been one of the main concerns in Jangouts development, but if we want to look into the future we need to pay that technical debt the sooner the better. The current approach to UI has become a limiting factor. Some examples:

 - It was requested to change the way to pin a participant [1]. It was implemented, but the result is far from optimal (I will elaborate in a separate mail with links to demos).
 - The underlying parts needed to make possible to change a participant's name [2] were also implemented, but we were not able to find a way to make it fit in the current UI
 - If somebody decides to implement per-user volume [3], they will have the same problem.
 - I also have in mind a "local mute" feature (see this comment [4]), but once again I wouldn't know where to place that button.
 - Screen sharing needs better handling. One possible approach suggested in [5].

Moreover, there are some usability problems we keep hitting all the time:

 - The button to mute yourself can move if somebody else (who is displayed before you) enters the room.

 - The name of the room is not displayed.

And another piece of information about the room that should be displayed somewhere
https://github.com/jangouts/jangouts/issues/158
 

[Ancor Gonzalez Sosa]

I believe I found a better way of having the best of both worlds. Check it at 

https://jangouts.tk/ui3/

As you can see, clicking on the thumbnail makes the feed sticky. Clicking on the feed's name reveals the additional actions. The caret (triangle) preceding the name should make that obvious.

I believe that's a better solution because:

 - It makes those people that wanted click-on-thumbnail-to-stick happy

 - It gives us enough room for adding more buttons. In the worst case (very little space reserved for the participants roster), we can still have up to 4 buttons.

 - It does not rely on hover, so better for touch devices

 - Since the action to make the feed sticky still has a (kind of redundant) button, the feature is more "discoverable".

If nobody is against, this will be the approach in the next release.

Cheers.

[Ancor Gonzalez Sosa]

El martes, 27 de diciembre de 2016, 13:26:01 (UTC+1), Ancor Gonzalez Sosa escribió:

In the previous message I sent to this list (Sept. 29th, zero replies so far) I wrote I would like to see some movement in the UI redesign, not only aesthetic, but specially from usability point of view.

So let me do a second attempt to get some discussion started.

It's pretty obvious that usability has never been one of the main concerns in Jangouts development, but if we want to look into the future we need to pay that technical debt the sooner the better. The current approach to UI has become a limiting factor. Some examples:

 - It was requested to change the way to pin a participant [1]. It was implemented, but the result is far from optimal (I will elaborate in a separate mail with links to demos).
 - The underlying parts needed to make possible to change a participant's name [2] were also implemented, but we were not able to find a way to make it fit in the current UI
 - If somebody decides to implement per-user volume [3], they will have the same problem.
 - I also have in mind a "local mute" feature (see this comment [4]), but once again I wouldn't know where to place that button.
 - Screen sharing needs better handling. One possible approach suggested in [5].

Moreover, there are some usability problems we keep hitting all the time:

 - The button to mute yourself can move if somebody else (who is displayed before you) enters the room.

 - The name of the room is not displayed.

And there are even more design decisions that some people dislike despite being conscious decisions taken by the developers (like [6]).

Last but not least, the current UI kind of works in mobile devices, but it's not 100% mobile friendly (buttons are too small and it relies too much in buttons that are only revealed on hover).

I would like to be enlightened with a new approach for the Jangouts UI, solving as many mentioned problems as possible and flexible enough for the future. I know myself well enough to know such idea will not come out of my mind. I need help from more clever people.

While I wait for such a revolutionary new concept, I have put together some small modifications here and there. The most pressing issues commented in my original mail should be now gone or mitigated.

The resulting code is still in review, but you can have a sneak peek at https://jangouts.tk/header/

Cheers.

[David Díaz]

[...]

While I wait for such a revolutionary new concept, I have put together some small modifications here and there. The most pressing issues commented in my original mail should be now gone or mitigated.

Hi Ancor!,

Happy New Year :).

It is not a revolutionary concept but, Why do not use those three vertical points to show available actions per feed? This kind of interface is very often used nowadays, and most popular and well-known applications have this button or a similar one.

In fact, it was the first idea that came to my mind while I read your publication past week. Even more, finally you finished implementing something similar, but... you know, maybe in a 2012 style ;) At least for me, with those icons in a row the feed's actions are neither accessible nor scalable. Why not include a caption close to the icon?

Since Jangouts is built over Angular, I'll propose you to use the Material Design Spec. The Google guys have a Material Angular framework [1] that provides you, in their words

> a set of reusable, well-tested, and accessible UI components based on Material Design

I believe those components could help you to have a more powerful and intuitive user interface since it is common to see them in current versions of many Android applications and also Youtube is testing their "material" UI.

Here [2] you have a(n ugly) Plunker showing more or less what I mean, although, in my opinion, the "more options" button should be in the top right corner.

I chose the Angular Material 2 [3]. I know it is in beta and under active development, but

* the md-menu directive allows choosing x and y position in this version; for me, it makes sense to show the feed's options from bottom to top in the current button position.

* Jangouts has an angular-2 branch; if you decide to use angular-material for the look & feel, maybe it is better to do it in the angular-2 version.

Regarding the header, to be honest, I do not like it. Sorry. It is icon-bloated, isn't it? I hope to find some free time within the next days to think and make a proposal.

Regards

[1] https://material.angularjs.org/latest/
[2] http://plnkr.co/edit/TnGxlsHa3w8HDex3enx1?p=preview
[3] https://github.com/angular/material2
 

[Ancor Gonzalez Sosa]

2017-01-02 1:08 GMT+01:00 David Díaz <diazgl...@gmail.com>:

[...]

While I wait for such a revolutionary new concept, I have put together some small modifications here and there. The most pressing issues commented in my original mail should be now gone or mitigated.

Hi Ancor!,

Happy New Year :).

It is not a revolutionary concept but, Why do not use those three vertical points to show available actions per feed? This kind of interface is very often used nowadays, and most popular and well-known applications have this button or a similar one.

In fact, it was the first idea that came to my mind while I read your publication past week. Even more, finally you finished implementing something similar, but... you know, maybe in a 2012 style ;) At least for me, with those icons in a row the feed's actions are neither accessible nor scalable. Why not include a caption close to the icon?

I already did it in my first attempt and I still believe it would be the right approach in the end. BUT.... :)

Take into account that in the current UI, the thumbnails can be scaled down to a minimum of 48px wide (if you want to see that in action without the need of inviting 15 people to your room, just scale down the area dedicated to the list of participants). In that situation, the approach with captions was not that good (in my first attempt, at least). Squared icons are easy to re-distribute dynamically to fit in such a tiny place. If fact, with 48px thumbnails the buttons are not displayed as a row, but in a more convenient way that could support up to 4 buttons. Hard to achieve with captions.

Of course, we could use a responsive approach, showing the captions if they fit and only icons if not... but I only had spare time for a hack. :-)

Since Jangouts is built over Angular, I'll propose you to use the Material Design Spec. The Google guys have a Material Angular framework [1] that provides you, in their words

> a set of reusable, well-tested, and accessible UI components based on Material Design

I believe those components could help you to have a more powerful and intuitive user interface since it is common to see them in current versions of many Android applications and also Youtube is testing their "material" UI.

Here [2] you have a(n ugly) Plunker showing more or less what I mean, although, in my opinion, the "more options" button should be in the top right corner.

I chose the Angular Material 2 [3]. I know it is in beta and under active development, but

* the md-menu directive allows choosing x and y position in this version; for me, it makes sense to show the feed's options from bottom to top in the current button position.

* Jangouts has an angular-2 branch; if you decide to use angular-material for the look & feel, maybe it is better to do it in the angular-2 version.

Sounds like a great plan. If we manage to release a 0.5.0 version based on Angular2 (see https://groups.google.com/d/msg/jangouts/ehOmpBdW3dk/Z4sxOfEkAgAJ), a redesign with Material would be a nice goal for 0.6.0.

Regarding the header, to be honest, I do not like it. Sorry. It is icon-bloated, isn't it?

Yes, it is. Extremely bloated I would say. :-)
 

I hope to find some free time within the next days to think and make a proposal.

Cool!
 

Regards

[1] https://material.angularjs.org/latest/
[2] http://plnkr.co/edit/TnGxlsHa3w8HDex3enx1?p=preview
[3] https://github.com/angular/material2
 

The resulting code is still in review, but you can have a sneak peek at https://jangouts.tk/header/

Cheers.

I'm all ears (erm... eyes).

[1] https://github.com/jangouts/jangouts/issues/131

[2] https://github.com/jangouts/jangouts/issues/15

[3] https://github.com/jangouts/jangouts/issues/22

[4] https://github.com/jangouts/jangouts/issues/22#issuecomment-259167767

[5] https://github.com/jangouts/jangouts/issues/160

[6] https://github.com/jangouts/jangouts/issues/162

--
You received this message because you are subscribed to the Google Groups "jangouts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jangouts+unsubscribe@googlegroups.com.
To post to this group, send email to jang...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jangouts/a1f91d82-6645-4a26-8b9c-73f3e4cc5fe0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ancor González Sosa

[cyn...@gmail.com]

I am against the proposition to use Material Design in Jangouts. 

We made the mistake of trying it in another SUSE project, and we really regret it. The documentation is really bad (and we are talking about the one that is finished, for Angular 1.. the one for Angular 2, AFAIK is not ready yet) and it is 100% flex based, which is actually not a good practice since Flex should be applied in special cases when needed, not for an absolute griding system. This makes Angular Material really "un-unflexible" for certain UI design in terms that everything is flexible and that is not always the case.

In the other hand, AFAIK and as already mentioned, there is still no documentation for Material design for angular 2 since it is under development.

Last, but not least, I understand the concept from Google of unifying the look and feel of the products people, users in general, use around the internet. But isn't it to their advantage only since we would all be implementing Google style in our products to then lose our identity and let all our application look like they were made by Google? And in terms of the UX, I think we can agree to certain standards like the 3 dotted point in the corner that David mentioned, which is even coming in the new guidelines of SUSE products, because it is true many other products are using it. But I rather take time and research, or use the researches we make internally at SUSE for the benefit of a product made by SUSE employees and not by Google.

I think that we are already a "copy" of a google product (Hangouts, in a way), and making it look more like Google would be a terrible mistake. 

We are building (yes, slowly) an identity different to Google Hangout for a reason. To stand out and be something unique, open source, completely free, etc. I would stick to that direction.

[David Díaz]

Thanks for your arguments. I have to admit most of them have convinced me.

Just to clarify, obviously I don't know the internal research's at SUSE, but the proposition to use Material Design was far from making Jangouts look like a Google product. Simply as a quick way to improve its UI using standards and techniques commonly used nowadays.