PDA

View Full Version : [Feature Request] Cut off long replies


g00fy
12-31-2007, 03:30 PM
Hi,


Is there a possibility that you can add an option to cut of a reply after x levels (I think difficult), or after x kb (easier) of data? Now when you reply the whole thread is sent to the other side, even from like ages ago...
Although there is a catch in this in that that only the reply should be taken into account for the # of kb because otherwise you might end up stripping your own -lengthy- reply!


Greetings

dfroberg
12-31-2007, 07:17 PM
+1

Would be nice with some way of doing "cleaning" automagically, I know how many times a day I manually cut away stuff from replies... I doubt g00fy & myself are the only ones :)

joegeck
01-01-2008, 02:27 AM
I went ahead and added this request to our bug software. The developers should eventually get around to evaluating whether it's a worthwhile and/or possible change.

http://www.wgmdev.com/jira/browse/CHD-416

g00fy
01-01-2008, 03:22 AM
Thanks for the creations ;)

jstanden
01-01-2008, 07:46 AM
Yeah, some kind of heuristic is possible. But if you guys are writing replies above the quoted text and you are quoting the entire message below it, you are part of the problem. A customer can only quote back as much as you send them in the first place.

RFC1855 (http://tools.ietf.org/html/rfc1855):
Be brief without being overly terse. When replying to a message, include enough original material to be understood but no more. It is extremely bad form to simply reply to a message by including all the previous message: edit out all the irrelevant material.I'm not a pedant about most RFCs, but dealing with e-mail every day for 6 years made a huge peeve out of this. ;)

dfroberg
01-01-2008, 03:43 PM
Well so we are *complying* with the RFC manually :)
Now how do we automate it :)

/D

g00fy
01-01-2008, 04:12 PM
The main reason why I add my text above is that you can see immediately the email. To have the history you need to read backwards which is a little weird, but ok...
I know a good reason is not "because most other email clients/web clients do it that way", but yeah, that's another reason.

jstanden
01-03-2008, 08:11 AM
Well so we are *complying* with the RFC manually :)
Now how do we automate it :)I like that attitude! :D

There are a couple requests involved here:
http://www.wgmdev.com/jira/browse/CHD-416 (your request)
http://www.wgmdev.com/jira/browse/CHD-219 (hiding quoted blocks)

When I get a couple minutes, I can experiment with a couple ideas. Personally, I liked CHD-219 when it came up. That's how Gmail chose to attack the problem.

It's pretty easy to create a filter in the template for that message content and do just about anything.

Scanning lines for something like this would be easy enough:
>newest
>>>>>newer
>>>>>>>>oldest

The problem on anything like that isn't actually writing the code, it's more about:
What arbitrary values do we pick? e.g., the max depth or # of KB, etc.
Where would we put the configuration for it? Is it worth the clutter of making it configurable?Those types of concerns are the real obstacles when reviewing feature requests. I can't remember the last time we were stumped on the coding part. ;)

As far as code cleanliness though, I favor the CHD-219 approach of condensing:


This is my reply
>>>long history
>>>>>>is fully quoted
>>>>>>>>>here
into:

This is my reply.
[click to show quoted text]
Even with something like that we'd still need a decent heuristic, since some people reply above the quotes, some people reply below the quotes, and others (like me) reply to several quoted excerpts. We'd probably just want to look for a bunch of quoted lines in a row at the top or bottom (say 5+), and ignore everything else. It would be counter-productive to have to 'click to show' 10 times to read a message with several quoted excerpts.

Thoughts?

g00fy
01-03-2008, 10:13 AM
I like the way GMail does it. But then again, it's getting send to the customer, which imho is useless (the sending)... As maybe he doesn't have gmail or similar features.

What would be EXTREMELY cool (and equally difficult) would be to only strip the latest piece of the conversation & store that in the database. Then when you reply, you just send 3 conversations back with & all is done.

;-)

g00fy
01-03-2008, 04:45 PM
Or maybe you want to cut off after an # of lines?

jstanden
01-04-2008, 10:38 AM
I like the way GMail does it. But then again, it's getting send to the customer, which imho is useless (the sending)... As maybe he doesn't have gmail or similar features.

It's a good point, but I think if our 'quote & reply' feature was intelligent and removed the extra quoted blocks then we wouldn't be sending that much content at the user to boomerang back at us.

I quoted the RFC because it's essentially saying what I'm saying -- it's your job to not send that much quoted text to the recipient. If you quote 3 lines and add 4 lines to the discussion, that's the most they can throw back at you in a quote. Then you simply crop their reply and repeat.

Yes, it takes a couple seconds of your time to edit the quote for context -- just like it does on the forums here. ;)

The main thing we just need to be careful about is not going overboard with heuristics -- because it can backfire. It may start stripping off too much quoted text which then requires much more effort on your part to copy/paste it back.

I fully support the idea of hiding long quoted blocks while reading tickets. That's an efficiency booster -- because you can't really control customer behavior. Many people are going to quote an entire message back at you for as long as e-mail exists and e-mail clients make it the default.

But I'm wary of pushing that into the "Reply" area -- because, as I've said, that's really where your job, as a rational human being, begins. You can spend 15 seconds picking an appropriate quoted excerpt before drafting your reply. You can do that a thousand times better than a conventional computer can (or a conventional super star coder, for that matter).

g00fy
01-04-2008, 11:15 AM
I completely agree with your point but what I really would like to see in the messages area is something that only shows the last reply, because now - as you said - it shows the entire thread which the customer send us... Quite annoying ;-)

jstanden
01-10-2008, 12:01 AM
Makes perfect sense. :) This thread is linked to your feature request.

MrKurt
01-10-2008, 03:06 AM
I'd be happy with a checkbox that said "don't include the original message in my reply". I can copy and paste what I want to include myself, I don't need it preloaded. :)

Hildy
01-10-2008, 05:22 PM
I'd be happy with a checkbox that said "don't include the original message in my reply". I can copy and paste what I want to include myself, I don't need it preloaded. :)
If you just want it to not quote the previous message, edit cerb4/plugins/cerberusweb.core/templates/display/rpl/reply.tpl.php. Lines 98-99 are {/if}On {$message->created_date|date_format}, {$headers.from} wrote:
{$message->getContent()|trim|escape|indent:1:'> '}Change that to {/if}

jstanden
01-10-2008, 10:16 PM
Yeah, we can probably just add a button for "Reply" and "Quote&Reply" again.

I'd hate to clutter things up with too many buttons -- but for the people who prefer this, situationally, it saves a few keystrokes.

Hildy
01-11-2008, 08:13 PM
Yeah, we can probably just add a button for "Reply" and "Quote&Reply" again.

I'd hate to clutter things up with too many buttons -- but for the people who prefer this, situationally, it saves a few keystrokes.
What about a hidden button? I can do all the backend and frontend work of having it distinguish whether to quote or not, and then just wrap the button in {if true==false}{/if}. Would still have the cleaner look, but people could turn it on if they want it.

jstanden
01-14-2008, 07:29 AM
What about a hidden button?

Sure, that or a Worker Preference is fine with me. The preferences at least prevent some of the SVN conflicts from coming up.

I've been meaning to add some layout customization somewhere (to reorder the main menu as well), but I haven't gotten around to it. ;)