Implement pinning posts and displaying pinned posts #140
Conversation
sk22
commented
May 6, 2022
sk22
commented
- Added a tab that displays pinned posts, fixes Pinned toots are not shown in profile #29
- Added options to the context menu for pinning/unpinning posts
|
|
|
okay, now apparently, newly created posts sometimes get displayed under "pinned"… i'm not sure why tho |
You need to add a check for your new filter type to |
|
(I'm not sure it's a good idea UX-wise to have them as a separate tab in the profile though — we need our designer to take a look at this) |
Yes, thanks! Here's what I've been considering: Many other apps implement pinned posts by displaying them on top of the Posts timeline. Since you can pin multiple posts on Mastodon, this could result in quite a bad UX quickly - having to scroll down all pinned posts to finally find the newest ones. So I've been considering displaying just the newest pinned post and having an UI element above (maybe looking like the "In reply to …" one?) link to a page (or tab?) displaying all pinned posts? |
Maybe it can be solved by adding a button to collapse all pinned toots? |
Maybe we should display one on the main timeline and a button leading to the pin section for more? |
|
The Material 3 redesign already has pinned posts (and featured hashtags too) incorporated into the profile. |
|
Wait Mastodon app gets a Material 3 redesign? |
|
Yes. Part of it is already in production, in the onboarding flow. The iOS app is also moving closer to the iOS UI guidelines. |
I am not sure we should move in that direction though. You know, Mastodon apps' UI is part of Mastodon's brand. If we cut it all off, the app would just look like everyting else (like a stock Android app), it wouldn't be so much unique. Take an example of how Mastodon's web interface looks like. If we've removed all the fancy stuff to look like other websites we would only evolve backwards. Instead of going Material 3, I would suggest considering the redesign the web interface to fully match the apps' UIs. If Material 3 happens, the apps and the web version would just look like 2 completely separate projects (like unofficial forks). Design parity and feature parity is very important. Please don't become Proton (Techlore talked about how Proton's feature parity is a mess right now, trust me it's not what we want here). It may be a question of taste, but expect backlash. I don't support going Material 3. |
|
However, I think applying guidelines is a two sided thing; it can be good somewhere (apps imitating they're stock android apps, but other than somewhere it is just off, and doesn't work. (Twitter for example) |
That's the point?
The web is a blank canvas. There are no UI guidelines for it and it's fully platform-agnostic. So everyone rolls their own UI system. Apps are not like that though — there is a certain degree of adherence to a common design language expected from native apps on all mobile platforms (it's a mess on desktop though, especially on everything that isn't macOS). In my own opinion, a good native app looks like it's part of the system. |
Again, taste and opinions. Plus, you as a developer may seem like it is a good idea, but end users may not. I suggest asking the community about this one at least. If more than 50% want this to be a thing, I won't put any barriers in the way to implement this, because I can use as much forks as I want, but I want to help for those who don't know about forks exist, and do not like the Material 3 design language (like Nick at TheLinuxExperiment). |
As said in the readme, the course of development of this project is not decided upon by the community. We're working with a professional designer off of our internal roadmaps. This is also the reason why I won't merge any pull requests that modify the UI. |
This redesign is not the ridiculous tasteless Google thing they did 2 years ago, of course. For one, everything will remain sanely sized and margins won't occupy half the screen space like they do in the notification shade on Android 12 and 13. It's more about colors than anything else. |
|
I'm closing this since I'm not going to merge it anyway now that there's an existing implementation. |
