New list item component, action menu mobile use and accessbility

[ChristophWurst]

Mail uses the new app content list item component from nc/vue. This looks and works great on desktop, but on mobile there is a little accessibility issue IMO. The issues is that by default we always show the timestamp of the message, on hover (desktop) the actions menu handle shows. There is no hover on mobile, so that menu is a "hidden" feature. You can still click and get a menu, but a user wouldn't know about this.

@nextcloud/designers possibly something to discuss

[skjnldsv]

iirc, this is a two-step tab, when you tab the menu appear, no @marcoambrosini ?
We talked about this in the past, what was the decision?

[marcoambrosini]

Yes it is @skjnldsv though on mobile there's no tab key :)
The thinking behind this was that we were going to require users to open the item and act on the menu in the AppContent, which should mirror every action that's present in the ListItem menu. For talk and other apps this is perfectly fine, but I can see how this can make the process of deleting or archiving emails a bit more tedious.

[skjnldsv]

Sorry, didn't thought of mobile.
Well, like I said like 10k times, that's why no one should hide a menu.
I had this talk far too many times, I don't have time for this anymore, please raise to @jancborchardt and see his call.

[ChristophWurst]

@jancborchardt @nimisha-vijay could one of you look into this?

[raimund-schluessler]

I don't know if it fits here, but I just noticed that tabbing through the messages only works forwards. Tabbing backwards (with shift+tab) does not work.

[marcoambrosini]

As an input, this is how Hey, Protonmail and Gmail solve this problem.

Screen.Recording.2021-08-18.at.15.50.13.mov

RPReplay_Final1629294203.MP4

RPReplay_Final1629294153.MP4

Currently, tapping the avatar doesn't do anything other than showing a tooltip with the name of the contact. We could remove that (it's shown already as the title of the listitem anyway) and trigger selection mode on tap. That way actions would be always available in the topbar.

[jancborchardt]

I’m not fully sure about the discoverability of that, especially because when you want to change 1 thing you don’t think about multiselect. Also, you need to press on the left of an element, the opposite of where you normally go. @nimisha-vijay @skjnldsv @ChristophWurst what do you think?

Whatever we go with: For mobile it would be nice that the currently active element also shows the menu, so when you go back to open the navigation it directly shows.

[ChristophWurst]

Whatever we go with: For mobile it would be nice that the currently active element also shows the menu, so when you go back to open the navigation it directly shows.

For Mail that means you have to open each of the messages to reveal the menu. If you just open your inbox then there is no menu handle.

[marcoambrosini]

For mobile it would be nice that the currently active element also shows the menu

This wouldn't help here because the list would be collapsed on tap and the active element hidden to make room for the content.

What about having the selection checkbox always visible on mobile, similar to gmail?

[jancborchardt]

So @marcoambrosini @nimisha-vijay and I talked about this and came to the conclusion:

• The menu icon will default to not showing on mobile, unless otherwise specified by the app developer. E.g. in Mail it would always make sense to show, since actions like moving or deleting mail are quite frequent (as opposed to Talk conversations).
• We do always recommend to put the actions in the list as well as in the element itself, like in Talk and Mail already.
• Multiselect is nice to have for sure, but a different discussion from this.
• We can have additional "helpers" to get to the menu like on desktop file browsers where when you navigate back up from a folder, the folder is highlighted. We can do the same and also show the menu. (This is just a helper, not a main way to access it for sure.)

@ChristophWurst @skjnldsv what do you think?

[marcoambrosini]

I transfered to the vue repo since it doesn't affect mail only.

So I guess that we need some sort of forceDisplayAction prop, right? So what should happen to counter and details when this is toggled on? Should we just offset both to the left? @jancborchardt @nimishavijay
Not a huge fan but I can't come up with anything else 🤔

[skjnldsv]

• The menu icon will default to not showing on mobile, unless otherwise specified by the app developer. E.g. in Mail it would always make sense to show, since actions like moving or deleting mail are quite frequent (as opposed to Talk conversations).

How would that solve the fact that it's basically not accessible on mobile at all.
You cannot focus the entry, you need to click it. Long press is not supported.
Mobile is often heavily bound to low bandwidth network or low cpu power. Meaning openin an entire room in talk and loading participants, messages and previews just to "mark as read" is not acceptable

[marcoambrosini]

In my view we can default with actions on on mobile too in the case of talk, as long as we don't reintroduce them in the main (desktop) web UI

[nimishavijay]

IMO the actions in the menu are not always frequently used. Hiding them for some cases is okay, especially when it takes valuable real estate on a tiny screen. This needs to be thought about for each app though, we can't just hide the menus in all the apps.
I think showing the menu for all apps on mobile is okay as a starting point because right now none of them are accessible, and then later we can think about the actions in it and if they are useful.

[skjnldsv]

I think showing the menu for all apps on mobile is okay as a starting point because right now none of them are accessible, and then later we can think about the actions in it and if they are useful.

Thank you. @marcoambrosini can you do that please?

[marcoambrosini]

Thank you. @marcoambrosini can you do that please?

Sure, I'm just not sure about how it should look, hence this.
Anyone has a better idea?

[jancborchardt]

I think showing the menu for all apps on mobile is okay as a starting point because right now none of them are accessible, and then later we can think about the actions in it and if they are useful.

Yup, sounds good. And then making it look like Marco proposed at #2340 (comment) would work.

In my view we can default with actions on on mobile too in the case of talk, as long as we don't reintroduce them in the main (desktop) web UI

The issue here is that the differentiation is not mobile/desktop, but it’s touch/non-touch, and we can’t reliably differentiate that. People might have a tablet which is as big as some screens (iPad Pro) or they have a laptop with a touchscreen.