Clicking anywhere in a status should open it #479

Open
opened 2019-04-05 19:27:59 +00:00 by feld · 7 comments
Owner

Just like twitter. Requiring the user to know they should click the timestamp is an anti-pattern

Just like twitter. Requiring the user to know they should click the timestamp is an anti-pattern
Owner

There's been other issues about this too and it's not as straight forward, because it can very much be unwanted behavior just like on twitter and qvitter. I'm sure I'm not the only reason who hates it when clicking on normal text somewhere suddenly changes the layout radically. Qvitter at least did it in somewhat sane way where it would only expand a few posts (the reply-to status most importantly) and not the full 10-100 posts that are in the full thread (it then had an "expand full conversation" button), so accidental presses weren't so fatal. in our case accidental clicks/presses could have much worse consequences, especially considering 100+ status threads aren't as rare as I would like them to be.

Speaking from my own experience, on qvitter's mobile interface it was already frustrating enough to have the layout change with 1-2 statuses whenever you accidentally expanded something (because there was no safe areas on the screen where you could press without anything happening), and I can only imagine how bad it'd be with much larger changes.

I'm not exaggerating if I say that I would just stop using pleroma fe on mobile if this sort of behavior wasn't optional.

There's been other issues about this too and it's not as straight forward, because it can very much be unwanted behavior just like on twitter and qvitter. I'm sure I'm not the only reason who hates it when clicking on normal text somewhere suddenly changes the layout radically. Qvitter at least did it in somewhat sane way where it would only expand a few posts (the reply-to status most importantly) and not the full 10-100 posts that are in the full thread (it then had an "expand full conversation" button), so accidental presses weren't so fatal. in our case accidental clicks/presses could have much worse consequences, especially considering 100+ status threads aren't as rare as I would like them to be. Speaking from my own experience, on qvitter's mobile interface it was already frustrating enough to have the layout change with 1-2 statuses whenever you accidentally expanded something (because there was no safe areas on the screen where you could press without anything happening), and I can only imagine how bad it'd be with much larger changes. I'm not exaggerating if I say that I would just stop using pleroma fe on mobile if this sort of behavior wasn't optional.
Member

@shpuld We need to disable this by default and add a instance-level configuration to enable this one.

@shpuld We need to disable this by default and add a instance-level configuration to enable this one.
Member

can't this be configurable on account-level?

can't this be configurable on account-level?
Owner

it should be, and i think MR makes it that way

it should be, and i think MR makes it that way

I doubt this will land in Pleroma-FE because it's just so different from what people are used to. With more frontends on the horizon, I wonder if we should just close this.

I doubt this will land in Pleroma-FE because it's just so different from what people are used to. With more frontends on the horizon, I wonder if we should just close this.
Owner

i want this in pleroma-fe tho, it's especially needed on mobile

i want this in pleroma-fe tho, it's especially needed on mobile
Owner

I especially don't want it on mobile where mispresses happen all the time (especially in the current version with bad performance that makes more of them happen, and loading a big conversation can take seconds and seconds)

I think it should be brought back on the table when inline conversations and their expanding/collapsing aren't so damn shitty, pardon my french. I think it requires more work than just making collapsing easier.

I especially don't want it on mobile where mispresses happen all the time (especially in the current version with bad performance that makes more of them happen, and loading a big conversation can take seconds and seconds) I think it should be brought back on the table when inline conversations and their expanding/collapsing aren't so damn shitty, pardon my french. I think it requires more work than just making collapsing easier.
Sign in to join this conversation.
No milestone
No project
No assignees
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe#479
No description provided.