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.

don't really know, i think some of the demands are pretty obvious, like groups which are basically an outdated meme by now, post editing which is even older meme, circles, custom emoji reactions, settings sync in FE. You can add stickers and proper/simpler emoji management/packs there too.

At least to me in pleroma-fe there's no such thing as "not on roadmap", everything not closed is "eventually", and eventuality is determined by :

do i want to do this

does shp want to do this

does anyone else want to do this

is it (soft)blocked by anything else

is it even possible with current technology or without sacrificing other usecases

I don't see the need for complex voting system, and I don't think a lot of people will be interested in that, not to mention we don't have proper management nor many of us are working on project full-time for results to even matter.

Lastly, implementing proper online pool that's resistant to attacks is nearly impossible, it's hard as it is in real-life already, and implementing systematic pool has connotation that we'll be devoting to honor the results, which may or may not be the case in reality.

tag:git.pleroma.social,2020-05-23:71125Hécate opened issue #39: A community voting system at Pleroma / pleroma-meta2020-05-23T16:49:33ZkleidukosHécate

Background

With the augmentation of Pleroma "casual" users (not power users, not admins),
the ratio of people being involved in the development to Pleroma users is
slowly but steadily decreasing, which is pretty normal.
However, we do not have an efficient way to gather demands and other suggestions
from the wider community, outside of Gitlab issues and IRC rants.

Suggestion

My suggestion is to implement a model (loosely) based on the Swiss voting system:

Four dates per year during which the user base is asked to vote on features that
are not part of the roadmap. This would enable us to receive feedback on
those from people who use Pleroma while not being actively involved in its
development (which is bound to become the majority of the users).

Discussion

I would like to discuss some adjacent points regarding this suggestion, especially
the means we have to advertise and regulate a vote

Indeed, the Pleroma user base seems more fragmented than the Mastodon one.
In the Mastodon community, the #MastoAdmin
hashtag exists to discuss adminstration-related topics with their fellow admins.

I do not know of such a thing amongst Pleroma administrators, since many of them
use IRC to speak of such things.
My point here is that we should start creating privileged information feeds for
Pleroma administrators and users who care about their instance.

Please let me know if I forgot something.

Cheers!

tag:git.pleroma.social,2020-05-23:71124HJ opened issue #38: Making emoji fonts more accessible. at Pleroma / pleroma...2020-05-23T16:37:00ZhjHJ

Steps

Tag should render [emoji font="mario64"]lol[/emoji] into <span data-type="emoji-font" role="figure" aria-label="lol">:mario64-l::mario64-o::mario64-l:</span> and into pleroma.content['text/plain'] as lol

Step 4: add similar thing pleroma.content['text/plain'] to users and do same for user titles.

Definition, implementation details

Emoji-font emoji pack specifies how emoji fonts should work:

which characters are supported

case sensitivity

which case to use for plaintext version

symbol conversion (i.e. translating cyrillic symbols)

how emoji are formed, i.e. prefix

future features?

Emoji-font pack should be just a special case of a regular emoji pack.

this one is.. weird. Considering that we already do have things like mastodon't stripping out rich text from posts or some clients not displaying more than 4 images or not being able to show both poll and images in same post...

tag:git.pleroma.social,2020-05-08:68999feld opened issue #37: Tracking features of Federated instances at Pleroma / ...2020-05-08T19:45:32Zfeldfeld

We may need to start tracking features of federated instances 🤢

Chat is going to land in Pleroma soon and clients will need a way to search for users that you can send a Chat message to otherwise people will not want to use a feature where you cannot know if the other end is able to receive the message. This is just one example of many things that are probably coming down the pipe in the future, like knowing if you can do a voice/video call with a user (if we ever integrate that).

Repository json is just an index listing all available emoji packs for installation, which I assume not necessarily mean all emoji installed on the instance since repository can be just a static website (i.e. gitlab raw data)

Repository json lists download url and json specifying how to extract emojis from file and bind them to shortcodes

/api/pleroma/emoji/packs is used for...? It's not used in PleromaFE because pleroma FE just uses original pleroma emoji endpoint which i think added packs only recently? It used to have tags...

/api/pleroma/emoji/packs lists all emoji as they are installed instead of source zipball + json, which probably isn't legal for finmoji?

{"finmoji":{"license":"CC BY-NC-ND 4.0","homepage":"https://finland.fi/emoji/","description":"Finland is the first country in the world to publish its own set of country themed emojis. The Finland emoji collection contains 56 tongue-in-cheek emotions, which were created to explain some hard-to-describe Finnish emotions, Finnish words and customs.","src":"https://finland.fi/wp-content/uploads/2017/06/finland-emojis.zip","src_sha256":"2C1374795AA23C032B2E9ED68C695A0452BCBB13F77DB90E883E1233ACAD2DA5","files":"finmoji.json"},…}

Main difference being that the API puts the metadata fields other than files in the "pack" field and key names are dash-joined (kebab casing?) while the index.json puts the metadata fields directly and key names are in snake_case.

Currently only the index.html being served at /:maybe_nickname_or_id end point is getting the metadata injected. So this MR only addresses that endpoint.

In addition there currently isn't any auth being done by Phoenix on that page. So the only data I can preload is the instance data, public timelines etc. Even if the browser is logged in.

So I think other ways this could be pursued further would be to extend the preloading to other endpoints like /main/friends and /main/public. Also checking if the user is logged in and preloading the some per-user based data could be done. I can handle these things if people think there is enough of an upside.