pleroma-fe issueshttps://git.pleroma.social/pleroma/pleroma-fe/-/issues2020-08-31T12:30:30Zhttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/683Statuses with hidden content should hide poll options too2020-08-31T12:30:30ZtastyteaStatuses with hidden content should hide poll options tooI think statuses with hidden content should not expose the poll options. They could contain unpleasant content or there could be a lot of them. A poll with 20 options could have the subject “Long poll” or similar with the intention to no...I think statuses with hidden content should not expose the poll options. They could contain unpleasant content or there could be a lot of them. A poll with 20 options could have the subject “Long poll” or similar with the intention to not occupy the whole timeline.
![screenshot_2019-10-13T17-48-06](/uploads/51f203de262eff99bfafea428bf49dd3/screenshot_2019-10-13T17-48-06.png)
My version is bcfdd68e.https://git.pleroma.social/pleroma/pleroma-fe/-/issues/625Draft Issue. Groups: What are they? How they work?2019-10-28T09:50:03ZlainDraft Issue. Groups: What are they? How they work?Discussion / Evaluation issue.
The topic of group support came up again on IRC. Backend-wise, the topic is rather clear. A bigger question is how groups are supposed to work for the user.
Backend issue for the thing that AP calls group...Discussion / Evaluation issue.
The topic of group support came up again on IRC. Backend-wise, the topic is rather clear. A bigger question is how groups are supposed to work for the user.
Backend issue for the thing that AP calls groups: https://git.pleroma.social/pleroma/pleroma/issues/656
Current state of groups on the fediverse:
# Gnu Social
Groups federate. You can join groups on other servers. Posting in a group happens via putting a ! (e.g.: `!cofe`) in front of the group name in a post, otherwise these posts are normal posts. A user has to join a group before they can post to it.
I don't remember if there were private groups or not, and if so, how that worked. Please somebody add that info.
Posting to multiple groups at the same time is possible.
# Gab
Groups do not federate. Groups have an id, name, description and banner. UI is like this.
![Screenshot_2019-07-29_Gab_Social_1_](/uploads/707871c422756d509b14e42bb21be583/Screenshot_2019-07-29_Gab_Social_1_.png)
![Screenshot_2019-07-29_Gab_Social](/uploads/b735166c450336ff267e6ff1ed0cfbd7/Screenshot_2019-07-29_Gab_Social.jpg)
Client side, the post api is extended with a `group_id`. If you use that, the post is internally associated with that group. As far as I can tell, this does not federate at all, although I read on fedi that they federate the id. I can't find it in the activity json, though (https://gab.com/users/pennyfortheguy/statuses/102525197179306906.json).
Posting to multiple groups at the same time is not possible.
# Misskey
[NOT CHECKED, COULD BE WRONG. WILL ADD]
Groups don't federate.
# Other, non fedi
I think most people associate something different than the GS groups with the name 'groups', more along the lines of gab groups (that is, a page you go to and then you post there). Another popular feature is the whatsapp style chat group. It might make sense to call all these different expectations of users by different names in the frontend, even if they are implemented similarly on the backend.
Ideas:
- Gab style groups: Groups (I suspect this is the thing most non-GS users associate with groups)
- GS style groups: Federated Hashtags (They behave more like hashtags you can follow)
- Whatsapp style group: Chat Group. Similar to Gab style groups, but map a long conversation instead of a set of thematically similar posts.https://git.pleroma.social/pleroma/pleroma-fe/-/issues/624Future UI/UX2020-06-04T13:18:26ZlainFuture UI/UXThis is more of discussion forum than an issue.
The current UI/UX of Pleroma has evolved over time from a simplified clone of the Qvitter UI to a complexified clone of the Qvitter UI. Lots of idiosyncrasies stem from this history, beca...This is more of discussion forum than an issue.
The current UI/UX of Pleroma has evolved over time from a simplified clone of the Qvitter UI to a complexified clone of the Qvitter UI. Lots of idiosyncrasies stem from this history, because features were implemented either because Qvitter did it like that or 'it was the easiest' at time.
Things that come to mind:
- Visiting a thread page by clicking on the time, expanding the thread by clicking on +
- Clicking on a user avatar in a post expands the user card, but clicking on it in the card goes to the user page. Clicking on the user name always goes to the user page and never opens the card.
- Settings, settings, settings. Split between two different pages.
- Posting is 'silent': Except for the new post appearing, there's no visual feedback that something really happened.
- and so on... (feel free to add more examples)
All of these were created for good reasons. For example, the card allows you to quickly follow / unfollow a user without leaving the current context. The settings are split between profile editing and the rest. Still, these are often interactions that no other software than pleroma has, and many new users struggle with them because there's no way to find out how to use Pleroma without clicking around everywhere. I've seen people close to giving up on the 'unusable' frontend until someone pointed them to some of the basic features like thread expansion. I wonder how many people we are losing immediately because they just can't figure anything out.
Attached is the UI/UX sketch that @sheueyen / ida on IRC has done, as an example of a different look and feel. I think it's a good look at the system from an outsider / new user who is familiar with UX questions. Not all interactions are sketched here, just a general look-and-feel.
![Pleroma-Preview_AllArtboards](/uploads/52ffa1a4ef17be78af8862adc1cba492/Pleroma-Preview_AllArtboards.png)https://git.pleroma.social/pleroma/pleroma-fe/-/issues/593Images should default to 'sensitive' when a Subject/Content Warning is used2020-06-04T16:07:15ZOctopus OctopusImages should default to 'sensitive' when a Subject/Content Warning is usedI'm gonna be honest I can't imagine anyone finding use for this behavior especially when images with subjects are hidden on PleromaFE itself. It's not obvious to pleromafe users that their content is being displayed in full for everyone ...I'm gonna be honest I can't imagine anyone finding use for this behavior especially when images with subjects are hidden on PleromaFE itself. It's not obvious to pleromafe users that their content is being displayed in full for everyone who isn't using PleromaFE, causing them to seem incredibly inconsiderate of others.
For reference, the bottom post contains a sensitive image, the top post does not.
![image](/uploads/b8457b58f1f6e3a382307ed62ea323a5/image.png)
on mastodon.social
![image](/uploads/1af4e41633259a971b579194640410c2/image.png)
on tusky
![Screenshot_20190624-234031_Tusky](/uploads/f02983c3e919f5cf744129d054df890b/Screenshot_20190624-234031_Tusky.png)https://git.pleroma.social/pleroma/pleroma-fe/-/issues/481Remove "Mentions" TL?2019-07-29T16:26:21ZHJRemove "Mentions" TL?Should we do it? Do people use it in the age of working notifications?
I know I use it like once a year to find some post but I could live without it.Should we do it? Do people use it in the age of working notifications?
I know I use it like once a year to find some post but I could live without it.HJHJ