Block Users

[Ueda]

Please add where blocking a user also hides anything in the forum, such as their avatar in the last reply of a forum topic (make it show the previous reply.) Also, make the sidebar widgets hide their stuff as well, and remove them from the Activity feed. I do not want to see people I block there either.

[TSP]

This gets complicated real fast though. Personally I've never liked the idea of a ignore system in a forum system. I find it just as easy to simply ignore any user or post I don't want to see in my own mind "manually" by scrolling it out of view. This is something I even do automatically sometimes. Generally though I find that I'd like to read all replies in topics, even if they're from people I don't like. I understand the reasoning behind it in terms of the messaging system and mentions, however I feel most implementation outside of this is not necessary and frankly damaging to a community culture.

Anyway, whatever opinion you have about the need for this, there are some profound challenges I see in the extension of this system, both from a design and technical perspective: 

Challenge 1: Performance
Removing users from feeds such as "New content", topic lists and the like will provide you with major headaches when it comes to performance and optimization of pretty much all community features that has to do with members. There is a reason that IPS cache information about the last member that replied in a topic and the person that started it in the topics table. In a system where you don't want to be "notified" of new replies from certain members in topic and forum lists, they will have to disregard this cache for any members that ignores one or more users.

For something as simple as a topic list they will have to confer with the posts table in order to figure out how they should order the topics. They can't simply ignore the topic with the last reply from a ignored member, because there could be other new replies in the topic that you care about. Topics would need to be sorted in the order of the newest reply from members you hadn't ignored. It's also likely you wouldn't want the unread marker to show up if the unread replies are only from members you have ignored, so they would have to deal with that for each topic (although that would likely be one of the easiest challenges).

Challenge 2: User experience and expectations
The implementation that would likely provide the best user experience also have the biggest challenges in terms of performance (I have described the most performance hungry implementation above). However, you could choose to "cheat" and minimize the performance impact, but then you also trade that by negatively affecting the user experience by not fulfilling their user expectations fully. I'm really just making a best guess at what the majority of users would want in terms of how it should work for the optimal user experience and the drawbacks users would accept and understand. Figuring that out and then choose which concept design you would implement is really a challenge in itself.

"Cheating" the performance aspect can be done in the same way the current ignore system works when you view a topic. When you view a topic that has replies in it from members you have ignored, then all posts are still retrieved from that topic (with no questions asked by the system on whether you as a member ignore any of the authors or not). When it has fetched the posts for the current page it get's much easier and less of a performance hassle to simply query for whether you have ignored the member that each individual post comes from. If you have you can then collapse the post and provide the user with an explanation that they have ignored the author of the post (thereby "hiding"/collapsing the post). That explanation "need" to be in the topic view to avoid confusion as to why there are effectively fewer replies on some pages and to explain any confusion that may arise by not getting the entire context in the discussion (and provide the means to get the entire context). 

This concept can be translated to a topic list by replacing the name of the author with "Ignored user" in italic, unlink the username and replace the avatar for the user with the default one. That would give you a clear visual indication that you may not want to read the newest reply (or the topic itself). What it wouldn't give you is the other benefits like knowing whether their reply is the only newest one within the topic, the order of topics would still be the same as if you hadn't ignored etc.

As for topics started by someone you've ignored; Would you want those topics to show up at all in the topics list? There are likely different user opinions on this, which is part of the whole concept design challenge to begin with.

Challenge 3: Complexity
This ties in with both of the former challenges really. When you go into the rabbit hole of choosing to "improve" the ignore system, you'll have to deal with a lot more user expectation on how the system should optimally work and be extended to all sorts of other areas. You would get a lot more bug reports and support tickets by people confused by how the implementation of the system affects them in ways they didn't expect.

For example if you chose a variant where you still fetch all topics on the current page as normal: you could then choose as a developer to take the approach to reorder only the topics within the same page and update the last reply information and unread marker based on information you get when querying each individual topic on whether the last reply is from someone the member ignored. However, this can trigger questions from users like: "why is there topics on the bottom of the first page that is listed as older than the first topic on page 2?"

I could choose to try to tackle both challenge 1 and 2 to give each of them their most optimal outcome. However, overcoming the performance challenges in particular would most likely require a lot more additional data to be written to new tables in the database and increase the complexity of the code significantly. This would further increase the amount of bugs and challenge in implementing and improving other areas of the code.

In conclusion
I find this very challenging to explain in a clear way, especially in english, but this is my take on this from the perspective of being a developer. I could really go into a lot more detail on how one could try to solve the different challenges, but I really think this is more than enough for now. Maybe another developer see obvious solutions to the challenges presented that I either haven't thought of or deliberately chosen not to get into detail of here, but either way, this would be a very complex undertaking.