Forums Feature Suggestions better ignore method

I've always found using /ignore on someone in a channel rather useless, because the result is generally that I end up seeing half conversations that others are still having with that person.
I end up unignoring the person again, because I tend to find that even more annoying than seeing the person I wanted to ignore.

What I suggest is the following, why not create a client-side ignore feature that collapses what the person says by default, and optionally lets me view their text if I'm curious? That way I get the best of both worlds: I don't really see what that person is saying, but I do still get to look it up if someone's response to him intrigues me.

Example:

<other_person> troll: you're really annoying
<troll> [+]
<other_person> troll: ok, that IS a very good point

me .oO (I wonder what he said..)
* me clicks on the expand button

<other_person> troll: you're really annoying
<troll> [-] other_person: luckily you all have this new ignore feature for people like me
<other_person> troll: ok, that IS a very good point

Wouldn't that be much nicer to have than the current version, where I'd just see:

<other_person> troll: you're really annoying
<other_person> troll: ok, that IS a very good point

Hopefully others agree with me that this would be very nice to have, and this will be a reality some time in the future..

-ko9

It kind of defeat the purpose of ignoring them but why not.
I don't think the collapse/expand idea is possible with the current way the channel window works but you could for example script something that would display the text of ignored people with a black text on a black background.

What you're asking for would basically require a complete rewrite of the channel (and query) display windows. I really don't think there's enough benefit to make that worth doing. Most ignore systems out there are just like this one... if ignored, the person is entirely ignored. And people are used to them. With the amount of work required, I don't think it's going to happen.

That said, I think there are some feature requests that have come in over time that would also require rewriting some or all of the display system for channels/queries. If Khaled decides to tackle those, then including this at the same time might be an option.

In the meantime, Wims's idea of just using the same foreground and background colors on the text would accomplish the same thing. You would just highlight the text instead of "expanding" it. It's also a fairly easy thing to script and you can add a variety of options to personalize it that wouldn't necessarily be available from a built-in feature.

I agree with the colour suggestion, this was my first thought. A simple proof of concept would be:



Then instead of expanding with a [+] button, you would simply highlight the line.

As was pointed out, this basically defeats the purpose of ignoring somebody, since /ignore is most often used to stop flooders, not so that you don't have to read a legitimate users text (I find that usage of /ignore a little childish, but that's just me). In the case of a flood, showing the message, even if the data is hidden, would still create a flood of data on your screen. This is something that is better scripted for those users who need it.

edit: Added Wims modification for "isignore"

or simply if ($nick isignore) {

Good point I totally forgot about isignore. Updated code sample.

I'm not sure how you can say it would require a complete rewrite without having access to the source code. Many pieces of software have features that lie dormant and just need switching on. That could be the case here!

In any event, I wonder if something could be worked into the hotline routine so that the black text/background colour idea becomes visible when hovered over.

The windows are text-based. If it was that easy to add other controls and things to the channel window, then emoticons would have been added years ago. The chances of it being simple are extremely remote.

Agreed that the chances of it being easy are remote, but nobody knows for sure. Can we leave comments about how easy a feature would be to implement out of this forum and just comment on the feature itself? Only khaled knows how easy it is and whether it's worthwhile to implement something.

Personally I like the idea.

There really isn't anything wrong with pointing out 1) how unlikely something is to be added.. at least anytime soon, and 2) that is is probably going to take considerable work to accomplish.

Obviously, if there is no evidence to support the claims, then you shouldn't just guess. Or at the very least, you should state that it's a pure guess. But there is ample evidence to show that the channel windows are text based and that any additional controls or graphics is not a current feature. And from a programming standpoint, changing a text-only control to also include graphics or trees (what this feature would use) is not just "flipping a switch."

When people ask for a feature that has over an extremely high chance to require a lot of work, then it's better to tell them that right from the start. It lets them know that it probably won't happen anytime soon and may not happen at all. If something will be easy to implement, then telling them that gives them hope that it could be seen in the next version or two. Khaled doesn't typically reply to feature requests except on rare occasions when he says it will be in the next version. Most people like to at least have an idea if it's likely to happen and if it's likely to happen soon. Yes, people don't like hearing "no" and they don't like people disagreeing with their suggestions, but the world is not about puffing up people's egos by always saying "yes" or agreeing with them. Disagreeing with something is just as valuable as agreeing with it.

It's not for me or you to say how hard a feature is to implement or how likely it is to be implemented, that's all for the developer to say.

I'm not asking you to blindly agree with every feature, just to comment on the feature itself rather than other matters that shouldn't concern you.

None of us can possibly say how hard or how likely any feature is to be added.

Telling people something is easy or hard to implement is simply misleading as none of us can see the source code. Something that sounds easy could be hard due to the way mirc is written.

It just seems like every suggestion lately is shot down by people who think they know khaleds programming ability ("such and such a feature is too hard") or people who think they know what his todo list contains ("such and such a feature will take up time used for more important features ")

Let's just stop trying to be know it alls and comment on what we actually know about: the feature suggestion itself.

Fine then. I'll shoot it down instead of offering some useful comments. The idea is bad. It's not worth adding. It is something that should be scripted. Most people are not going to want, need, or use it. It isn't remotely common in any other software with an ignore feature. Changing the standard /ignore method is a bad idea. Personalized protection like this should never be part of mIRC, but should always be scripted as the person needs or wants. Maybe you can't script tree views, but you can accomplish the same thing and that was shown above. I also don't see a benefit of making it possible to script tree views in the channel windows. I do see the benefit of allowing a filter for the window where you can select nicks that you want to see text from as that can be very useful when trying to find something that was said. But tree views? Definitely not.

Now, I think my comment to the OP previously is a lot more useful and less negative. It's something the OP can use to either improve the idea or make the decision not to worry about it. The alternative that I just showed, which is what I think specifically about the feature, is not anywhere as useful. It's what I think about the feature and it gives a very direct view of why the feature is bad (imo obviously), but that's all it does. Maybe instead of trying to protect the op's feelings, you might want to find out if the OP was in any way upset about my original comments and which type of comment he prefers. Personally, I'd much rather the first comment if it were my suggestion.

I never said it was "too hard." I never said Khaled couldn't or wouldn't do it. I never said it would keep him from doing some other feature. I simply pointed out that it would require redoing the message windows and that the feature is of limited use to most people so that by itself, it's unlikely to be worth the effort involved. I then pointed out that there are a number of other features (although I didn't originally list any, they include emoticons and images) which would also require changes to the message windows. By combining them and doing them all at the same time, it then becomes worth the effort because you aren't making major changes for one minor thing, but you are major making changes for a variety of things that would require similar kinds of changes to the code, including the very highly requested emoticons.

So I provided reasoning that though it's not likely by itself, it has a decent chance when combined with other requests.

As to the code... yes, I haven't seen it. However, I do know enough programming to know that these windows were designed with text in mind and were not designed to handle images, tree views, or anything else like that. I also know that trying to change that is not a minor thing to do. It wouldn't require the time that Unicode required, but it would require more than a little time to accomplish. It would also probably require considerable testing because that kind of change is prone to creating bugs.

Now, we're far off topic because of your complaint, so I will stop discussing that in this thread. If you'd like to continue to discuss the merits (or lack thereof) of telling people the way it really is, then we can take it to general discussion.

I really don't miss the catfights that take place on here. That said, I've only ever used the ignore feature to block flooding. Whilst the idea raised by the original poster isnt a bad one I've always found it more productive to use the ignore feature I was born with rather than shut annoying people out by pushing buttons.

When I get on the train to go to work each day I have to put up with morons yelling into their mobile phones, more often than not in foreign languages, and there's no technological ignore feature for that. I've never encountered a time on IRC that is worse than that.

Technological ignore feature

If the "[+]" was actually a treeview control toggle button, then you can pretty much forget about it. The buffer windows work through manual drawing of each character in the window, implementing dialog controls inside windows would mean Khaled would have to reinvent the wheel on dialog control drawing as well (not to mention the entire API for handling the interaction events)-- I'm fairly sure that's not going to happen just for one ignore feature request.

If the "[+]" is just an ASCII representation as I imagined it was, you could easily trigger a hover/click through a HOTLINK event. In this case, all mIRC needs is the ability to update channel buffers the way it does with @windows (through /iline, etc.)-- but this would also be a very big change, I imagine; perhaps a little more likely to happen at some point in the future though.

On that note, if the OP wrote a script to display channel info through custom @windows like some theme scripts already do, he could accomplish this through the method I described above. Of course using the colour code method is much easier and no less intuitive to use. In short, you might not get some treeview toggle control button, but there are various ways to do something almost equivalent in mIRC right now, and given how few people have requested this kind of a feature, I'd say that having any kind of existing reasonable solution should be good enough.

Yeah, an ASCII representation wouldn't be as difficult. However, considering the OP stated that he would click on it to expand it, I think the intention was that it worked like a tree view control. There are a variety of ways to accomplish the same basic thing using existing scripting. My comments were based solely on adding a tree control for ignore. "Hiding" text with color or using a hotlink method with a custom window or even making use of $tip with hotlinking could do the same kind of thing that what was requested without any change to mIRC.

Now, if a tree control were someday added, I could see the benefit of using that to group all messages from a person (in a row) and minimize those. For example, someone (bot or spammer or someone who just talks a lot) sends 10 lines without anyone talking in the middle. You could "minimize" that group of text so you'd see something like:

-<user1> hello
+<user2>
-<user3> hey!

Or even a way to minimize all text from a user temporarily (for hiding bots when you just want to look at conversation). I see more use out of that than for ignoring people. In any case, I don't think this would happen.