Create ListItem component

[marcoambrosini]

This component will be used for talk's conversations, mail's envelopes and contact's list items. The goal here is to have a unified 'layout component' that you can wrap with your custom one and add your own logic on top of it.

[jancborchardt]

@ma12-co this will tackle the first 2 issues at nextcloud/mail#2110, right? Let me know if there’s any way to test it with that. :)

[marcoambrosini]

@jancborchardt it will, but this is still very basic and it will need quite a bit of work to support all the features required by mail, contacts and talk.

[marcoambrosini]

Finally coming back to this.
To give a bit of an update: there has been some discussion around completely removing the actions from the conversation component in talk, since all the settings for each conversation are now in a separate dialog and not all over the place anymore. We thought that that was a bit too much and that the actions there were handy, albeit not mandatory anymore.
Finally we came up with a solution that de-clutters the UI and keeps the actions in the component but displays them only on hover and focus.
The drawback to this is obviously the discover-ability of the button. In talk we can afford this because we treat this menu as a secondary, shortcut-like type of thing: all the actions contained in it are also present in the main settings dialog, which is discover-able.
This is the proposed behavior:

Peek.2021-02-12.14-14.mp4

So while I'm pretty confident that this will work for talk, I'm not sure about the other apps that use the two lines layout on the right side (e.g. mail). I'd be happy to see the tendency of unifying actions in the main content and stop showing these columns of 3 dot buttons in the navigation, but I'm not sure that's a suitable solution for every app.

So I'd like to know from you @jancborchardt @ChristophWurst and @skjnldsv what are your thoughts on this. Should we have a toggle for these 2 types of layout? Should we have only one type?

[skjnldsv]

I like the design! Looks really nice.

The drawback to this is obviously the discover-ability of the button. In talk we can afford this because we treat this menu as a secondary, shortcut-like type of thing: all the actions contained in it are also present in the main settings dialog, which is discover-able.

As usual, the show-on-hover is strongly advised against for accessibility purpose. It's non-discoverable and incompatible with touch devices. :/
The issue is not the keyboards, if it's focused, then it can be shown (granted, it's still bad as you have something that suddenly appear)

I'm afraid I can't agree with anything else that would always show the menu by default.
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

[skjnldsv]

Because there is a lot more spacing now, I might suggest we add a bit more width to the Navigation section, so that showing the three-dot menu becomes less invasive.

[marcoambrosini]

I'm afraid I can't agree with anything else that would always show the menu by default.
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

If we commit to this to the letter, by extension all talk's messages should show the 3 dot menus permanently. So we'd have yet another column of those. If we take the spirit over the letter, I think there's room for discussion on when we might want do the hover/focus trick.

[skjnldsv]

If we commit to this to the letter, by extension all talk's messages should show the 3 dot menus permanently

Yep, I've said it numerous time too 🤷

[marcoambrosini]

Yep, I've said it numerous time too shrug

Well it seems that we're about to have 2 buttons per message now, so that would be even more messy.
To me a UI with 50+ buttons on display on a normal screen size is not something we should aim at. We'd probably meet those criteria, but it would create so much cognitive load on the user that it would be less usable and thus less accessible for everybody.

@jancborchardt can you please share your take here?

[skjnldsv]

To me a UI with 50+ buttons on display on a normal screen size is not something we should aim at. We'd probably meet those criteria, but it would create so much cognitive load on the user that it would be less usable and thus less accessible for everybody.

Not disagreeing here, the design won't be as nifty. I don't make the accessibility guidelines nor am I directly concerned by this as I am grateful to have proper vision. But I'm sure that if any of us had accessibility issues or were using voice command all day long, we would not have this "debate".

[jancborchardt]

So in the example of the menu for the individual Talk messages: This should show on hover or focus of message, but also on tap of the message → problem solved there for touchscreens.

For the navigation menus it's a bit different since of course it opens something on tap and changes the view.
So what we could do is to make sure that the actions in the menu are accessible exactly the same in a menu inside the content. Basically like we do for the Android Files app, where you can long-press on a file, or open it and go to the 3-dot menu in the header.

What do you think about those 2 fixes?

[marcoambrosini]

Upon further reading of

https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

It seems that we'd only need to add the ability to dismiss the triggered hover state by pressing esc to meet the success criteria.. Or am I missing something?

[skjnldsv]

What do you think about those 2 fixes?

I'm honestly fine with any solution that take everything into account :)
I'm loving Marco's design, but I'm also loving people being able to use our software lol
It's annoying to have to find a middleground of course, and I would have loved to have a better solution to give. I'm just raising concerns here so it's not skipped 🤗

It seems that we'd only need to add the ability to dismiss the triggered hover state by pressing esc to meet the success criteria.. Or am I missing something?

Good question. Maybe my link was not the best suitable ressource. I found it by memory in my bookmarks.
Maybe we should invest a bit more reading into the a11y and w3 guidelines to see how to properly comply?

[skjnldsv]

@ma12-co maybe there is a way to detect touch screens?
If so always show on touch devices?

That doesn't cover the keyboard-only-no-mouse usage. But if the menu is focusable and appear on focus, that might be ok for keyboard with//or keyboards? 🤔

[jancborchardt]

@ma12-co maybe there is a way to detect touch screens?
If so always show on touch devices?

Not sure about that, cause:

• There are devices which have a touchscreen but people often use them with keyboard + mouse.
• The default UI will look different on different devices, which is not really normal (except when it’s different sizes)

[marcoambrosini]

Btw.: The documentation is missing the general usage of the AppContentList* components. I.e., it would be helpful to provide a description of the intended hierarchy. E.g., I'm not sure if the following usage is correct

Thinking about this, in talk we really use this component in other places, like the participant selection for a new group conversation, or the participant display in the right sidebar.
I would just keep it as a general purpose tall, avatar/text/actions/details/counter component.
Because of that, we could just call it listItem maybe?
cc @skjnldsv

[skjnldsv]

I would just keep it as a general purpose tall

I would as well, yes.
Same as the ListItemIcon

[marcoambrosini]

current state, I've been testing with talk and I think this is ready for review

Peek.2021-03-29.13-39.mp4

[skjnldsv]

Don't forget to rebase and squash though! ⚠️

[nickvergessen]

🐘

ooold