pleroma-fe issueshttps://git.pleroma.social/pleroma/pleroma-fe/-/issues2023-04-03T21:58:43Zhttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/948Should chat input box block typing when sending?2023-04-03T21:58:43ZShpuld ShpludsonShould chat input box block typing when sending?So currently chat input box uses same post status form which blocks all interaction while it's sending, it makes sense for statuses. When chatting you often want to start typing the next message immediately after hitting enter, but this ...So currently chat input box uses same post status form which blocks all interaction while it's sending, it makes sense for statuses. When chatting you often want to start typing the next message immediately after hitting enter, but this mechanism blocks it, it becomes very clunky.
The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.https://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/604Settings overhaul/refactoring2020-06-01T12:29:38ZHJSettings overhaul/refactoringMaster-task for improving settings and customization experience
## Settings unification and synchronization
* User settings must be merged with with just settings to avoid confusion that's there already.
* Settings synchronization must...Master-task for improving settings and customization experience
## Settings unification and synchronization
* User settings must be merged with with just settings to avoid confusion that's there already.
* Settings synchronization must be implemented
* Settings import/export must be implemented.
### Merging settings screens.
**Problem**: There are too many tabs - user settings/profile barely fit on english version already, adding settings tabs will make them extremely clunky to use.
**Proposed solution**: Tabs could be rearranged when merging, ~~but neater way would be using vertical tabs - this would make UI more in line with other settings screens in other software, which gives ease of use due to familiarity.~~ We can rearrange tabs in such way that there aren't too many of them.
**Problem**: It's not entirely clear what settings affect current FE and what affect all clients, which you need to submit and which not.
**Proposed Solution**: Luckily, there's not a whole lot of such options so they could be grouped together with a hint saying that it affects all clients. And stuff like import/export mutes/blocks is already kinda implies required action.
### Settings synchronization and import/export
**Problem**: There is a case where synchronization is undesirable just one or two little settings, personal example - i want images ON on my home computer but OFF on my work laptop.
**Proposed Solution**: have an advanced feature "subprofiles", which require explicit editing and track specific changes only. Editing is available only in "advanced" mode, while by default "Work" and "Streamer" modes provided by default - work mode disables displaying of images in posts (existing feature), streamer mode disables showing DMs (needs to be implemented), initially you can only apply one mode and currently active mode isn't synced.
**Problem**: There needs to me some control over syncing since you could have conflicts from using pleroma from two machines at same time, among other things.
**Proposed solution**: Provide indicator that sync is being done, keep track of time sync was being made, warn about conflicts when syncing (check what is there before uploading), allow pausing of syncing, manual load and save. This will also allow better control over syncing mechanism so that you can for example debug someone else's state by pausing your sync (should be done automatically) to not fuck up your own state on server (and possibly everywhere).
## User profile edit
User profile edit should be more intuitive and based off actual user profile, i.e. like other services allow it - to edit profile on what looks like your own profile card.HJHJhttps://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.HJHJhttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/479Clicking anywhere in a status should open it2023-04-03T21:56:07ZfeldClicking anywhere in a status should open itJust like twitter. Requiring the user to know they should click the timestamp is an anti-patternJust like twitter. Requiring the user to know they should click the timestamp is an anti-pattern