-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Simplify comment action menu for most common actions. #26927
Comments
Current assignee @JmillsExpensify is eligible for the NewFeature assigner, not assigning anyone new. |
Job added to Upwork: https://www.upwork.com/jobs/~01e41d6a1dad5b7475 |
Triggered auto assignment to Contributor Plus for review of internal employee PR - @eVoloshchak ( |
Marked this as internal because we'll work with an agency or C+ on this one. |
cc @shawnborton @dannymcclain @trjExpensify Any other comments before I move this one forward? |
Actually on that note: One doubt I still have is that I currently have three quick emoji actions mocked up for large screens, but because of how we have a dedicated row for small screens, there's just a lot more space for four plus the add emoji icon. Maybe that's ok even though it's technically "inconsistent"? |
Hm, I'm not sure about that inconsistency to be honest. Is one more emoji to stay consistent really that egregious? Especially as you can also right-click on desktop to see the same menu as mobile, so there can be a visible diff on the same screen as well. |
Hmm it's a fair point. How did we decide only three emojis on desktop and not four? Either way though I don't think it's a huge deal, but let's just be clear about our decision as I can already anticipate the bug reports coming in. |
I also don't think it's a big deal and don't really see it as an "inconsistency" as much as just adapting the UI to the viewport it's being display on. Like if we didn't show emojis on one but did on the other, I would call that an inconsistency. But I don't have super duper strong feelings either way to be honest. I did want to echo what Shawn said—we should be sure we document the decision to avoid unnecessary bug reports 🐛. |
Yeah, I just can't see a super clear reason for it. For example, if the extra emoji on desktop/web causes the menu items to overlap reactions or messages to the left, that would make sense. But I don't think they do, so I would just keep the number of them consistent across all platforms personally. |
We're going to add a join thread option to the comment menu, so if we keep 4 emoji and then add that, then we're back to the current amount of options in the main comment action menu. At that point, I kind of question why we should even add an three dot overflow menu. Unless we're saying that that'll automatically go into the overflow menu? |
Why wouldn't we put |
Just speaking for myself, I use that one a bunch. |
Same, but I think it's a power user thing. I've never been frustrated with where it is in Slack either, so I think it's fine in the overflow menu. |
Ok cool. Down with that approach then. |
We still need to get to this, though admittedly it doesn't feel like a priority right now. |
Still feels like low priority. |
Same as above. We'll come back to this later. |
Not a priority |
@dubielzyk-expensify This might be a good issue for you to lead given that you're doing quite a bit of polish and cleaning up designs through out the app. No worries though if you have a lot going on! |
No hot takes from me, I love all of this and I agree where you landed with your exploration. Nice job! |
Hm, I use "mark unread" all the time, easily 10x more often than the sum of everything else. Can we please not put that behind an overflow? |
"Subscribe to thread" can definitely go (I didn't even know it existed). |
Copy link also seems like a kind of poweruser thing that happens very rarely |
I sorta think we could move "open thread" behind the overflow as well, and just make pressing the chat itself open the thread. |
I use "subscribe to thread" and "open thread" pretty much all the time, less so "mark as unread". That said, I could live with "subscribe to thread going behind the three dot overflow menu. I think the issue we're going to face is that we all use products differently. |
All in all, I think Jon nailed it! |
Love what you've done Jon! I think both of your updated |
Are we good to move forward with this one? Not exactly a priority but I still think it's nice polish for the chat experience. |
✅ This is ready:
Specced up and ready here:Your comment (with and without attachment) Comment from someone (with and without attachment) New "Reply in thread" iconI do think we'll need a new "Reply in thread" icon. I'll do that work as a separate ticket and implementation, but I suggest something like this: I've started a thread in Slack for this. |
Great call on |
Not overdue. Think this is ready though |
Yes, I think we're aligned on this point. Would you mind posting a summary in #product in Slack as a final confirmation? Then we can get this assigned out. |
Done and done. Slack link |
Looks like you have lots of support in the Slack thread! |
Closing since we have a duplicate issue now. |
Problem
As we increasingly build out our chat-focused features, the amount of available comment actions has increased pretty dramatically from a couple to ten and counting. It's pretty daunting to say the least. Just as importantly, this creates a dynamic where our least common actions have equal screen real estate next to actions that are incredibly common, which introduces decide fatigue when you just want to come into New Expensify, collaborate, and generally get great stuff done.
Solution
In order to reduce decision-fatigue, free up precious real estate and help users find the most common things they'd like to do, let's simplify the comment action menu, as follows:
:+1:
), heart (:heart:
) and joy (:joy
)That looks like this for large screens.
Overflow menu selected
And it ends up looking like this for small screens.
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: