Forums/Community/Product Feedback

PlannedDoneNot planned

Formatted text in Tickets, not forum

jo
suggested this on November 09, 2008 13:44

Hi,

Not sure how hard this is to do, but it would be really nice, is to have emails submitted as tickets to keep the color that was submitted.

Reason is my clients submit html/outlook rich text which shows red or other colors of things they want changed or updated, just to be clear. However, once inside the ticket, I don't see any color at all. (Luckily, from the server side, I get a CC of all originals at another mailbox so I can see what they really submitted originally, with the crossed-out text, colors, etc.)

In a related feature request, it would be nice to be able to put [code]...[/code] and just have it marked as code in the ticket and in the forums.

Thanks! You have a great product here!

 

 

Comments

User photo
Matt Pawl
hayes

Yes, this is about the only request from our agents that we have not been able to accommodate in our trial. Agents would very much like to bold or underline in ticket comments for emphasis. The very format tools available in the forum comments would be perfect. I also agree that inbound formatted / html comments would be a boon.

January 28, 2009 13:48
User photo
shadeBlue Administrator

+1 for this feature

The ability to markup, format, and set font properties for text in ticket would be a HUGE benefit.  

I would personally like to see these options:

Bold, Underline, Italic, Strikeout, Bullet List, Indent, Highlight, Font Style, Font Size, Text Color

 

Also the ability to insert graphic such as screenshot embedded in the content rather than as an attachements would be a major bonus.  

 

Thanks!

 

February 27, 2009 10:32
User photo
Björn Bauer

+1

March 02, 2009 07:45
User photo
Rich Coleman

+1 for this - BBE code would be fine.

March 04, 2009 07:14
User photo
Jeff McDonald

I'd like this as well. Tiny's strict xml filtering would be perfect for my needs. Specifically tables are useful for my science-y company's ticket requests.

June 12, 2009 14:17
User photo
Jeff McDonald

s/xml/xhtml/ :)

June 12, 2009 14:18
User photo
Johan Allard

+1,

preformatted text (code) would be the formatting I would use the most.

June 18, 2009 02:58
User photo
Anthony Constantino

Agreed.  My biggest grievance is that HTML links show the full URL.  Often this URL is huge and makes the email confusing and cluttered to read.

June 18, 2009 17:42
User photo
Toby Hobson

+1

Would be nice to have some form of wiki/bbe syntax, especially for html links

September 04, 2009 07:42
User photo
Derek Brown

Yes! This is our number one issue as we use Zendesk more, and SharePoint less. In instructions even basic formatting is so important for clear communication. Just like here in the Forum is fine.

I'd be interested in the reason it's not included already. Is there a complexity or downside that's not apparent?

September 11, 2009 00:20
User photo
Sherman Dickman
Postbox

This is huge.  We really need more control over the emails that get sent.  Bold, bullets, etc.

September 26, 2009 06:19
User photo
Richard Rosa

Yes, We need rich text formatting. This should be a standard feature.

September 30, 2009 12:42
User photo
Ben Kellermann

I actually search Google for "zendesk rich text" in hopes of finding a way to hopefully enable this option.  This post is all I could find.  I think this is currently Zendesk's biggest drawback.  I'm signing up for the RSS on this feed in hopes that it will be added soon.

October 08, 2009 06:22
User photo
Anthony Constantino

I used to want this but after using the rich text editor in the forums I changed my mind.  Please do not implement this feature without a good rich text editor.


The current editor is very buggy.  I can never tell if I put 1 space or 2 between lines.  Sometimes I think there's a space and then none appears.  I would not want to get an upgrade only to lose control over my ability to properly format an email.

 

Google held off for a long time before adding rich text to gmail.  I wouldn't mind you guys working on more important things first.  37 Signals seems to manage just fine without rich text too.

October 15, 2009 15:50
User photo
Jake Holman
Product Manager

Hi Guys,

Thanks for all the comments in this post, they're all detailed which is great news. 

However, I just wanted to make sure I added some points which I think need to be considered here. I come from a background in Email Marketing and Email Design so I speak from at least some experience.

When Emails get sent out, they are sent in something called Multipart/MIME format, which essentially means two versions of the Email is sent out.

  • One Plain Text Email - this is completely plain, no formatting, no bold, no underline. Text. Plain.
  • HTML Email - this is the Email complete with all HTML markup.
At the moment, you are able to change the HTML portion of your Email using the Template - but this is just a header/footer and the actual content of the Email isn't rich text (although it still forms part of the HTML Email). 

HTML in Email is, for lack of a better word, rubbish. It's hard to get right because it formats differently in the vast majority of Email Software - Outlook 2007, Hotmail, Gmail being amongst the worst (if you're as geeky as me check out http://www.email-standards.org/).

Not only this, but Spam Filter Software often negatively scores Email with a lot of HTML Markup, or Rich Text - that's a very general view, but using too much bold, underline and italic will usually be a good way to get in someone's spam tray. 

Then you get to the real crunch. Not everyone likes HTML or Rich Text Emails. In fact some people opt to receive only Plain Text Emails - or read Emails from their mobile device. As a result, these people won't even see a bold, underline or italic.

There's plenty of ways to workaround having no Rich Text Email. 
  • Use Character Emphasis, rather than bold - this is this needs *attention* and this is _important_
  • Long URLs? Then shorteners such as http://bit.ly work great
  • Need to show someone some code? http://pastie.org/ works great too.
With all this considered, perhaps some would like to re-consider this feature request, or feel free to tell me if no one agrees with me :)

Jake Holman
Zendesk Support

 

October 16, 2009 05:48
User photo
Derek Brown

To be perfectly honest Jake – this sounds like an excuse, not a reason. There are people, who remain outside my understanding, who insist on sending only text email. It drives me nuts in this day and age, so please appreciate that I have a predisposition to ranting on this subject.

 

OK we accept the inherent injustice of a world that renders HTML inconsistently.  It’s rather like the insight that democracy sucks, but not as much as the alternatives. Something is better than nothing. The fact is higher-fidelity formatting helps in communication. That’s why almost everything we read, print, web, email isn’t in one non-formatted  type.

 

I have to give detailed examples of copy changes to English as a second language Agents. Bold, color, indent, font, bullets, – these are all very powerful communications tools. That’s why they exist. They aren’t eye-candy. They are functional communication tools.

 

You’ve presented workarounds but that’s what they are. It’s OK to say “the development resources required to bring rich text editing to Zendesk, in a way we would be proud of,  is a lower priority  than other feature requests* is something we could all appreciate and understand. To argue that plain text is better – I don’t by that.

 

*respectfully*

Derek

 

 

October 16, 2009 06:05
User photo
Derek Brown

It's a cruel stab in the face of my argument to cut and paste from Microsoft Word and see the mess of HTML (which it looks like I can't edit).


I'll shut up now.

October 16, 2009 06:07
User photo
Sherman Dickman
Postbox

As someone who works a lot with email (I work at Postbox), I can say definitively that simple HTML should render fine in 99.99% of email clients out there and will not get caught in spam filters.  

Simple Bold, Italic, Underline, and ordered and unordered lists would go a long way.

Remember, we're using Zendesk to provide support.  Often times this requires several steps that people must follow (which makes lists great) and we would like to emphasize certain points WITHOUT HAVING TO RESORT TO USING ALL CAPS, WHICH SEEMS RUDE. 

Jake, you even used bullets in your response to this issue.

Ok, 'nuff said, thanks for listening.

October 16, 2009 06:14
User photo
Ben Kellermann

<!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:AllowPNG /> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:TrackMoves /> <w:TrackFormatting /> <w:PunctuationKerning /> <w:ValidateAgainstSchemas /> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:DoNotPromoteQF /> <w:LidThemeOther>EN-US</w:LidThemeOther> <w:LidThemeAsian>X-NONE</w:LidThemeAsian> <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript> <w:Compatibility> <w:BreakWrappedTables /> <w:SnapToGridInCell /> <w:WrapTextWithPunct /> <w:UseAsianBreakRules /> <w:DontGrowAutofit /> <w:SplitPgBreakAndParaMark /> <w:EnableOpenTypeKerning /> <w:DontFlipMirrorIndents /> <w:OverrideTableStyleHps /> </w:Compatibility> <m:mathPr> <m:mathFont m:val="Cambria Math" /> <m:brkBin m:val="before" /> <m:brkBinSub m:val="--" /> <m:smallFrac m:val="off" /> <m:dispDef /> <m:lMargin m:val="0" /> <m:rMargin m:val="0" /> <m:defJc m:val="centerGroup" /> <m:wrapIndent m:val="1440" /> <m:intLim m:val="subSup" /> <m:naryLim m:val="undOvr" /> </m:mathPr></w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true" DefSemiHidden="true" DefQFormat="false" DefPriority="99" LatentStyleCount="267"> <w:LsdException Locked="false" Priority="0" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Normal" /> <w:LsdException Locked="false" Priority="9" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="heading 1" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8" /> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9" /> <w:LsdException Locked="false" Priority="39" Name="toc 1" /> <w:LsdException Locked="false" Priority="39" Name="toc 2" /> <w:LsdException Locked="false" Priority="39" Name="toc 3" /> <w:LsdException Locked="false" Priority="39" Name="toc 4" /> <w:LsdException Locked="false" Priority="39" Name="toc 5" /> <w:LsdException Locked="false" Priority="39" Name="toc 6" /> <w:LsdException Locked="false" Priority="39" Name="toc 7" /> <w:LsdException Locked="false" Priority="39" Name="toc 8" /> <w:LsdException Locked="false" Priority="39" Name="toc 9" /> <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption" /> <w:LsdException Locked="false" Priority="10" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Title" /> <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font" /> <w:LsdException Locked="false" Priority="11" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtitle" /> <w:LsdException Locked="false" Priority="22" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Strong" /> <w:LsdException Locked="false" Priority="20" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Emphasis" /> <w:LsdException Locked="false" Priority="59" SemiHidden="false" UnhideWhenUsed="false" Name="Table Grid" /> <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text" /> <w:LsdException Locked="false" Priority="1" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="No Spacing" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 1" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 1" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 1" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 1" /> <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision" /> <w:LsdException Locked="false" Priority="34" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="List Paragraph" /> <w:LsdException Locked="false" Priority="29" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Quote" /> <w:LsdException Locked="false" Priority="30" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Quote" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 1" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 1" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 1" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 1" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 1" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 2" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 2" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 2" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 2" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 2" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 2" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 2" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 2" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 2" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 3" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 3" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 3" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 3" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 3" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 3" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 3" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 3" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 3" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 4" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 4" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 4" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 4" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 4" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 4" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 4" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 4" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 4" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 5" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 5" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 5" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 5" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 5" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 5" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 5" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 5" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 5" /> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 6" /> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 6" /> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 6" /> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6" /> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6" /> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 6" /> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 6" /> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6" /> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6" /> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6" /> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 6" /> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 6" /> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 6" /> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 6" /> <w:LsdException Locked="false" Priority="19" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis" /> <w:LsdException Locked="false" Priority="21" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis" /> <w:LsdException Locked="false" Priority="31" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference" /> <w:LsdException Locked="false" Priority="32" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Reference" /> <w:LsdException Locked="false" Priority="33" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Book Title" /> <w:LsdException Locked="false" Priority="37" Name="Bibliography" /> <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading" /> </w:LatentStyles> </xml><![endif]--> <!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-520092929 1073786111 9 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} p {mso-style-noshow:yes; mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> <!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} </style> <![endif]-->

Jake -

I appreciate your post.  I appreciate companies that actually post replies to their user's forums - Thank you.

However -   I can't speak for the other people that have posted, but my reason for adding to this conversation was not as much to make the tickets / emails look good for the customer, but more for an internal use.  Personally, i use a lot of detail in my tickets and I reference them frequently.  If formatting was an option, then I could find what I was looking for much easier.  I believe that most people know how to use asterisk and other forms of "Character Emphasis", easily, but simple want further options which is why this was posted.  As for customers that have various email clients, I believe that should be used at our digression.  If we get complaints about HTML formats, then we could always have the option to only submit our tickets in any format we choose.  I appreciate your comments, but believe that any requested (and optional to the user) features like this one should not be left out by your team simply because a small percentage of people *may* :) not know how to use them.

Please share your thoughts - Thank you

October 16, 2009 06:17
User photo
Derek Brown

I'll add one comment just so people don't think I'm completely deranged. When I submitted I had all that Word HTML/XML code on the in the post and screen. I've come back now and it's gone. I'm happy for that.


Sherman makes a good point +1

October 16, 2009 06:17
User photo
Ben Kellermann

Looks like I posted code as well since I typed it in another program. - Whoops - Hopefully that doesn't take away from my credibility any....... Thank

October 16, 2009 06:21
User photo
Charles HOPE

While briefly evaluating Zendesk over my coworker's shoulder, I was happy to see that rich text e-mail was available, as it wasn't in our previous support solution.  Now I see that it's unavailable here as well, in order to hold true to a doctrine of purity which, without irony, was expressed using the very same rich text features we ask for.  I understand that e-mailing a web page requires arcane HTML, but really, all I need is the basic features available right in this forum: bold, italics, bullets, and hot links.

October 31, 2009 15:07
User photo
Johan Allard

Ironically, the email updates we get from this post is exactly what we're crying out to get for tickets!

October 31, 2009 15:54
User photo
Toby Hobson

Jake I appeciate the tips you gave about pastie etc but we can't really expect our users to use various websites and then post links in their support tickets. By the nature of a support ticket the user is probably not in the best of moods when when create the ticket so pointing off to other sites is likely to make them really pi**ed!

I think Zendesk is great but as a software company we really need the ability to handle links, code blocks etc in our support tickets and this is the main thing holding us back from rolling out zendesk across our organization. It seems such a shame because as I say I'm a great fan

October 31, 2009 16:03
User photo
John Fitzgerald

I've been trying to fight it, but the lack of rich formatting is going to kill ZenDesk for us. The links in tickets look horrible, and the fact they can't bold, highlight, or do anything standard formatting is causing a ton of headaches. 

November 03, 2009 11:33
User photo
Alex
cloudera
+1
February 11, 2010 16:59
User photo
Doug

+1, (please add support for basic html functionality to tickets.)

It is interesting (and helpful)  that you can add something like blockquote tags around something, and it will show up correctly in the on-line version.

March 30, 2010 15:07
User photo
Doug

That's really strange. I could swear the blockquote tag was showing up as you would expect in the "Events" area of a ticket. When I looked again today, the less-than and greater-than characters were translated into entities and so lost the html interpretation. Maybe I was mistaken.

March 31, 2010 09:36
User photo
Bill Sapp

Any updates on when we could anticipate this feature being available?  I feel like this is an expectation most end users (and support folks) have of a helpdesk system.  I don't like asking my end users to modify their writing style because the system doesn't interpret something they wrote.

One positive note is that I've noticed that pasted screenshots in emails do translate into an attachment in ZenDesk.  I would like to see that possible from within the ZD interface as well, but it's a great start.  Now, if we can just get the text control a little more developed, you will improve an already spectacular product.

Thanks,
Bill

April 05, 2010 22:25
User photo
Jake Holman
Product Manager

There's no update on this at the moment. While I don't feel it's a technically challenging thing to implement, it has a number of key UI decisions we need to make on how we should implement it. This will invariably add time to something that hasn't even started yet.

Jake Holman
Zendesk

April 07, 2010 12:43
User photo
james gmail

-1

April 22, 2010 11:21
User photo
Mousumi Das Chaudhuri

You have it in the forums why...can't you add these features to the tickets? It would really really  help....

 

Thanks

April 27, 2010 12:01
User photo
Neil Lillemark
electriccloud

Mousumi has a good point.  If the e-mail ends up being flat-formatted, that doesn't mean that the thread has to represent things in the same manner.  I do understand that automating how to convert a block of text to indented format would be tricky to get right without some explicit delimiters, but I'd still like some option here to possibly get our point across.  When we do want to ship a code-snippet, it would be step in the right direction if at least the historical thread could show that as indented code and not a somewhat odd collection of left-justified text that is hard to decipher.

May 18, 2010 17:04
User photo
Jake Holman
Product Manager

Oh, meant to label this post a while ago. We'll be looking at ways of making this happen, we're currently thinking of changing the WYSIWYG editor we use in forums to something that's nicer to use and better to work with, which can also then be applied to Tickets. 

Once we've applied that to the Forums, we can then stab at it with Tickets too. So, it's getting there, but couldn't possibly say when.

May 18, 2010 17:27
User photo
Ben Greiner
forgetcomputers

Even if emails remain plain text (like they are) it would be great to...

1. improve the very buggy text editor in the forums, and

2. Add text editing to online tickets.

 

This is how 37 Signals does it and their solution works great!

http://productblog.37signals.com/products/2010/05/basecamp-gets-new...

May 26, 2010 07:55
User photo
Jake Holman
Product Manager

@Ben: Wow, that's exactly the sort of editor I think would be perfect for Zendesk. I'll get in touch with 37signals to see if this was something they made, or whether they're using some cool WYSIWYG. We're aware our current editor, TinyMCE, isn't the best in terms of usability.

May 26, 2010 07:59
User photo
Ben Greiner
forgetcomputers

@Jake. 37 Signals is here in town (Chicago) and one of our former employees manages their support desks so let me know if you need any contact info and where to send it.

May 26, 2010 09:30
User photo
Grace Look

Any update on this? I checked out the 37 signal link Ben shared, it looks simple and awesome to use. :) Would love to have this feature this helps us compose clearer, more organised replies (especially bold & bullet point features).

July 20, 2010 03:54
User photo
James McFarland

Request the following:

- inbound emails with inline images keep inline images.

- requires and on/off options when added, default is off, and people who don't need it won't be troubled with it

- See http://www.posterous.com for an example of a site that keeps images inline when pasted inline (e.g. from Outlook).

-- we need this since our clients do this: [screenshot] + comments + [screenshot] + comments + etc.

- +1 for the 37signals way of option to use Texttile formatting v. WYSIWIG also

 

 

August 24, 2010 10:52
User photo
Dave N

This has apparently been in the works for TWO YEARS and it is still not resolved? We were going to sign up for ZenDesk .. in fact spent the last week uploading all our data, training our people, etc .. and even started using it. 10-20 agents at $25/month is $250-$500 a month ... but this may be the deal killer. Two years and no WYSIWYG in comments .. really? REALLY?

October 12, 2010 12:14
User photo
Joshua Stengel

Having build a few CMSs in my day, I can sympathize with introducing WYSIWYG to people who will use it but who don't understand code.  In fact, in my last major CMS I only allowed plain textboxes that would allow manual entry of HTML (or custom BBS-style code), but no WYSIWYG. Most people just don't know the damage they can do even though "it looks fine to them."

All that said, my next CMS will be a hybrid.  I'll allow WYSIWYG input, but I the spent time to write server-side code to "de-crappify" it before it gets posted.  Copy/paste from Word, and it's translated into just basic HTML tags.  I think if you stick to just allowing some very basic HTML elements (bold, italics, lists, indent/outdent, blockquote, font-colors, links, and headings) and running a similar filter (either through JavaScript or on the server side) you would make a lot of people happy--or at least provide the option for admins to enable/disable it.  Sorry for not including "underline" in my list, but I happen to believe that that signifies a link and should not be used as a style element. 

I think the argument of using a character-based method of showing styled elements is valid but shifting that burden to agents is not.  There is no reason a <strong>string of text</strong> couldn't be automatically converted to *string of text* by code for the plain-text version.

There was a time when your reasoning was sound for sticking with plain text, but I think it might be time to revisit your stance. You all do a fantastic job of making the code work on behalf of the agents (and admins), and I think this is just another area where you could take on some of the formatting burden through code.

October 17, 2010 18:53
User photo
Jamin
KTM Parts

+1   I just realized our agents are not able to link items directly from our website which is now a huge issue. We need to copy and paste directly from our website when recommending products and it should look exactly like this:

 

3PW117960 KTM Moto Box by Ogio $64.99  
3PW101031-9 KTM Supertech R Boot by Alpinestars $474.99  
October 18, 2010 10:38
User photo
Ron Teitelbaum

Formatting Macros:

Having pictures inline is very important for support tickets.  I just wanted to send you a reminder that formatting and the ability to add images needs to carry over to macros.

October 29, 2010 12:19
User photo
Mbosico

+1 We want to include a lot of instructions and details in our ticket notes, and it would be very helpful to be able to Bold, Underline, Italic, Strikeout, Bullet List, Indent, Highlight, Font Style, Font Size, Text Color.

November 04, 2010 10:02
User photo
Jake Holman
Product Manager

@Mbosico: What would you be conveying with strikeout, hightlight, font style, font size and text color that you couldn't with simply using Bold, Underline and Italic?

November 04, 2010 10:09
User photo
Mbosico

Bold, Underline, and italic would be a welcome improvement and I would be very happy with that. You are correct, I could convey and communicate most of what I need with just these three.

In order of importance from highest to lowest, these are what I would like if I could pick:

  1. Bold
  2. Underline
  3. Font color
  4. Font size
  5. Highlight
  6. Bullet/Number list
  7. Italic
November 04, 2010 10:27
User photo
Dave N

Just inline images alone would be huge! Need inline images. Need to be able to convey step by step procedures with images. And unordered lists. Those two things would be such a huge improvement. The rest I think is nice, but not as required as images and list. 

November 04, 2010 11:18
User photo
Ron Teitelbaum

+1 on inline images.

November 04, 2010 11:21
User photo
Alex Pardy

+1  We are about to sign up with Zendesk and losing this functionality really worries me... I would prefer not having to trawl through a mailbox trying to find out how the email was originally intended.

November 16, 2010 04:51
User photo
Cedric Moschallski

Any roadmap for this feature or some formatting?

I would love to have at least bold, underline and italic... some basic tagging or wiki-like language would help me a lot right now. Also doing some list of steps or instructions without bullets or numbered lists looks ugly. The bottom-bar of this forum-post looks so nice to me...

How about only having the formatting online for now (when the customer is here on zendesk) not not included in email?

Any rough outlook?

I would also like to server as beta-tester, if possible...

December 06, 2010 08:35
User photo
Andrew J
BizStudio NZ

+1

Just the basic features would be a great step.  Bold, Italic.  Anything else might be nice too... though I hate the thought if huge long tickets with pics all over the show.  Some restriction is ok to control the user input.

December 06, 2010 21:19
User photo
Dave N

Agreed. I don't really care if the external user has any functionality beyond text, but the agent needs to be able to respond with inline pics to show the steps needing to be taken to rectify the issue.

December 07, 2010 13:35
User photo
Andrew J
BizStudio NZ

We always use attachments for pictorial instructions.  I would hate to delay development by asking for pics if that is more awkward...

December 07, 2010 16:33
User photo
Aaron

+10 for this.. as a design company, I and many of my clients (also design companies) reguarly send photos and emphasis which we want to track as tickets. Zendesk has progressed further than just simple helpdesk now thanks to your configurable API, and we want to be able to hold dialogue with our clients regarding design.

We've just been integrating Zendesk for a MAJOR Australian brand and our clients are very dissatisfied that they can't do this with their client corresepondance.

At the very least, we need

1) Inline attachments

2) Basic HTML such as Bold, Italic, link, bullets, inline images and it would be nice if you didnt mess with the <p> and <br/> tags that people have used to break up their messages!

Like people are saying, this is a MAJOR feature request that your users want.

Basecamp is really good at this as previously noted, we use basecamp for most of our correspondance, but without ticketing, it makes it very cumbersome to work with. We dont want ALL html, just the bits that people use everyday.

 

Basically, I want to use the following snippet in PHP and expect it to come out properly.

$message = strip_tags($description, '<a><b><strong><em><br><p><br /><img><ul><ol><li>');

 

Go on Zendesk, make it your new years resolution to sort this out once and for all!

December 15, 2010 16:58
User photo
Aaron

And frankly, I think that the small percentage of insanely geeky people who don't like HTML is a poor argument (you asked us to disagree!). If they dont like it, they've already set their email client to not show it. So they'll get plain text anyway.

Pure and simple, most *business users* use Outlook or Thunderbird. Why? Because it's standard. That means as a standard, they're pretty well used to HTML mail.

Not ALL HTML, we don't need spans and divs.. just the basics.. as a PHP developer, I know it's easy. You know it's easy. Your 'fans' want it and our customers need it.

This needs to be your #1 priority. Help us do what you say and help us to give our customers the best service experience possible.

December 15, 2010 17:03
User photo
Rich Coleman

IN... LINE.... ATTACHMENTS... =\

January 21, 2011 10:56
User photo
Pete P
qatarairways

This should also include a spell checker

January 24, 2011 12:35
User photo
Richard Bratcher - C08563

I agree with the horde. Basic formatting is the only thing holding me back from recommending our company convert to using ZenDesk as it's CRM tool.  As good
as the rest of it is, this is a show stopper for many of your potential customers.

March 01, 2011 12:57
User photo
Bill DAlessandro

It's totally ridiculous that ZenDesk can't support HTML in ticket comments. All I need is to be able to do some basic formatting (like in forum posts) and include a link to my FAQ. Plain text feels like a time warp to 1999.

March 09, 2011 14:07
User photo
Dave N

We are still waiting for this as well. Can't be that hard, but it doesn't seem to be too important for some reason. Maybe they are working on a Drupal and Google Apps integration instead? That would be ok.. ;-)

March 09, 2011 14:12
User photo
Jake Holman
Product Manager

Actually, it is important to us and it is hard to do. 

It involves changing a hell of a lot of moving parts, including ripping things out and putting brand new things in. All this takes a lot of planning and consideration around timing. 

That being said, I believe it's in the works for mid-year.

March 09, 2011 14:31
User photo
Andrew J
BizStudio NZ

Would now be a good time to declare if this is going to be PLUS only? 

I reckon it could be... no offense to those on regular plans (like us), but it is an advanced feature that would make more sense as a plus option than Business hours which really is needed for many of the features of Zendesk... 

We would upgrade to PLUS for this feature I think.

 

March 09, 2011 14:46
User photo
Jake Holman
Product Manager

@Andrew: Packaging discussions don't normally take place until we're near completion on the development of the feature in hand. That way we have full scope as to which package it fits in to best.

Plain English: I've no idea, as the discussion hasn't taken place yet!

March 09, 2011 14:56
User photo
Andrew J
BizStudio NZ

Thanks for that Jake,  as you will have noted, I did just ask this as a question.

The problem I can see, and have experienced myself, is that persons can follow a particular feature request, add their ideas/comments/thoughts etc...  and begin to anticipate eagerly the implementation... if that it then implemented in a plan that they cant justify... you have a lovely recipe to discontent.  

I love the Zendesk concept; but I do reckon that as soon as a feature that is the subject of a forum is being seriously developed it would be a good idea to give some indication of how it is likely to fit into the whole scheme of things.

Think about it (or ask management to), and thanks again for the comment.

March 09, 2011 15:04
User photo
Dave N

@Jake said: "Actually, it is important to us and it is hard to do. "

Oh, you mean you guys are going to do it the right way? Can't you just do it like any other software company? ... Release the feature even if it isn't working and fix it later? ha ha

Thanks ZenDesk! We have been using your product for about three months or so now. While we have not fully embraced it yet, it really is a great product. Keep up the good work.

March 09, 2011 15:07
User photo
Lwaddell
zingchart

+1 for this feature

March 23, 2011 14:04
User photo
Matt Hardy

+1 -- Any updates on ETA for this feature?

April 10, 2011 13:14
User photo
Jake Holman
Product Manager

@Matt: Please see my post earlier, look for the angry bald dude.

April 11, 2011 09:08
User photo
Jen Koren
Orderup

How many years to customers need to post their feedback before something as simple as text formatting is put into place?  WOW

June 09, 2011 11:47
User photo
Jake Holman
Product Manager

Just pasting in my response to a similar post over at https://support.zendesk.com/entries/12834-monospaced-unformatted-text

"Guys, I completely understand your frustrations here - we use our own product after all and long for the same awesome formatting when we're crafting our responses. 

However, it is not as simple as simply sticking a WYSIWYG editor into the tickets interface or supporting markdown. Zendesk is fundamentally an email processing ticketing system. That means that email is at the core of Zendesk, and making changes to that core comes with significant challenges. Not everything is as simple as it looks, we deliberately make implementations look simple as that's our job as Product Managers and Engineers.

There is no question of skill in our engineers here, it is simply a matter of getting our timing right so we can actually make this significant change as smoothly as we normally do, and making it look as simple as it should. That time is not too far from here. As I had hinted at earlier, you'll likely see movement on this during the second half of the year (which we've just entered)."

June 09, 2011 11:50
User photo
Sherman Dickman
Postbox

If it was easy to do, they would have done it by now.  

June 09, 2011 11:52
User photo
Jen Koren
Orderup

I was told by your support staff to add my feedback here per my recent ticket asking if this was an available option.  It's funny that when I do that I get this response from the same company.  

June 09, 2011 12:01
User photo
Hamish Campbell

+1

Markdown syntax or similar would be handy - or at least a subset. After all it's specifically designed to be readable as plain text OR formatted.

Heck even just *bold*, _italic_ and * bullets would be enough for some basic formatting.

June 15, 2011 17:00
User photo
Joe Brenner

It's good to see this finally being implemented. We've been using Zendesk for a few months now and the lack of ticket formatting has made us seriously consider abandoning it. In fact, I'm currently doing further research into alternatives.

We've been 'putting up' with poorly formatted tickets until now (and grumbling more and more loudly about it) but a recent exchange with a customer has brought it to a head. In fact, for that exchange, we did abandon Zendesk and went back to regular email because it would have been impossible otherwise.

Like many posters in this thread, we don't need full HTML, but certain features are a must:

  • Inline images so we (and customers) can include a screen shot, or whatever, and comment on it, or we can provide detailed step-by-step instructions with illustrations instead of saying "now look at the attached image called BlahBlah.png".
  • Bullets and numbered lists.
  • Bold and italic. We don't actually use these very often but they certainly have their uses, especially for sub-headings without separate heading formatting.
  • Indents and blank lines. It's all about communication. Indented text (often a URL) makes it stand out more. Blank lines after lists, images and other paragraphs give them more breathing space and make the communication clearer. Yes, they really do.
  • Tables would be nice to have for tabular information (such as price lists or quotes) but a monospaced type (is that a code block?) would suffice so we could at least present tabular info using spaces, so long as those extra spaces don't get stripped out like they do at the moment - it's sooooo annoying!
  • Content from emails to be preserved as much as possible, including the above. 99% of our clients contact us by email and reply to our ticket responses by email. They don't log in to our Zendesk and use the online forms. They use email. Of course, as Agents, we use the forms but we're a lot more patient and forgiving than clients. ;)

 

I'm sure others require more that that, but that's all we need right now. It's funny to hear the arguments against sending out HTML emails when every notification to Agents and Clients has HTML content already.

Anyway, can't wait to see this feature appear. Literally. We'll hold on for another month or two but not much longer.

Joe

P.S. As a Basecamp user, their simplified editor is not all that great. It can be really frustrating to get content looking right. I nearly always end up using the Textile editor with a few extra <br /> and other HTML thrown in which kind of defeats the point of having a WYSIWYG editor. Even that is preferable to not having any formatting but you can't expect clients to use or understand it.

 

 

June 16, 2011 04:06
User photo
phil starkovich

I have nothing new to say.

Just wanted to add yet another comment to the thread to make sure you understand how important this feature is and how much we would all like it added.

If you added this one feature, there would never be a reason to even consider your competition. Without it, our decision was much more difficult.

Thanks! 

June 23, 2011 18:53
User photo
Jake Holman
Product Manager

@Hamish: We did consider doing some form of "markdown" but ultimately a large majority of our user base probably wouldn't really get it. It's nice on places like GitHub, but you're not writing 30+ tickets daily on there. 

@Joe: Yep, understand all your points. I do love Basecamp's simplified editor too, and we may well end up forking it and running with it - but we'd need to test all of these things before. We certainly won't be running with the current editor we have in place for forums though. 

On the tables point. I can see this being somewhat bloat for most users of Zendesk. It certainly has it's use cases and I totally get them, but like you said there's other ways to achieve the same things. Not discrediting it at this stage though.

Content preservation is certainly one of those things that will be the most challenging when we implement rich text. Pretty much every mail client has their own way of producing (and rendering for that matter) their own HTML. For example, Outlook uses Word to produce HTML... a word processor! That means we'd not only have to preserve, but validate and fix incoming content. For that reason we may only focus on the outbound first. 

June 23, 2011 19:07
User photo
Joe Brenner

Hi Jake, thanks for listening.

Just a further comment about content preservation... for me, it's not really about getting the rendering exactly right, it's about preserving the same subset of features that we're asking for in the editor. The actual layout doesn't have to be identical. Communicating the intent of the message is what's important.

So when a client embeds an image, all I want is to see that image embedded at the same place within the text. For example, I don't care if it's indented by 20 pixels instead of the 26 pixels defined in the original HTML, or not indented at all, so long as when a client writes "Here's a screenshot:", the screen shot actually follows the text.

I also don't care too much about particular fonts. Text is text. The only exception to this is where a monospaced font has been used (e.g. for laying out a table). Again, the actual font is unimportant so long as it remains monospaced .

Other things that need to be preserved: Bold, Italic and Colour (sometimes clients highlight points in colour and refer to the text "in green" - obviously useless if it all ends up black). Plus lists and line breaks, of course.

I hope that helps! What does everyone else think about this matter?

Joe

June 24, 2011 05:14
User photo
Anna Rys

I could totally use some simple text-editing. As someone already said, even just bold, italic and underline would do.

June 24, 2011 07:27
User photo
Jordan Khoviteri-Zadeh
Kildrummy.com

Just another +1...

June 28, 2011 05:57
User photo
Richard Bysouth
AJB Systems

@Joe - you've explained our need exactly. Customers never do anything too fancy when asking for support - it's always bold, italic or underline that they use to emphasise their points. Bullet points / numbered lists are occasionally used too, as are inline images (these are always hard to follow as our current support system sticks them all at the end!)

Anything else can be stripped out if necessary.

Looking forward to seeing this feature some time soon...

July 05, 2011 13:31
User photo
Brian Kaliher
livescribe

Definitely need this feature!!  

 

We use full articles (topics) as email templates to help resolve our customers' issues.  These include bullets, numbered/lettered lists, indents, bold, underline, font colors, and links to other articles (URLs not visible - just the article titles) all to make it very clear as the customer is working through troubleshooting steps on how to proceed and to keep emails looking professional.  

 

We are in the process of switching companies to handle our Knowledge Base, Forums, and ticketing process, and right now retaining the formatting we use would be the best thing Zendesk could do for our customer support.

July 06, 2011 15:25
User photo
Josh

+1 with an emphasis on adding links and images in.  Just adding in a plaintext URL makes an email look ugly, and much of our help is visual. 

The ability to drop in a *macro* with links and images would go far in making Zendesk something I like rather than complain about.

July 13, 2011 13:18
User photo
Rich Coleman

I take it that having an option to allow "HTML as-is" is not being considered?  Yes, some email clients screw up Word formatting etc. but who cares?  I would just prefer that the email client does what the it does and html just be left alone (you could even have an option that pops up a text-only version that strips out tags if it's not read-able with HTML).  If it looks funky - so be it. 90% of the time, it'll look fine and I'm sure 100% of the time the intent behind the message will conveyed.  If agents are sending crazy HTML that breaks in mail.aol.com then the customer will complain to the agent and the agent will know not to paste some crazy HTML into their ticket.  If the customer pastes some crazy HTML into their client and sends it in, the agent will be bright enough to figure out the intent of the email message.

July 13, 2011 13:29
User photo
Jake Holman
Product Manager

@Rich: That would be fine if Zendesk were a desktop app. However, because we're web based we're using HTML to render the page too. That means if there's dirty or bad HTML in the email/comment and we simply display it on the page, we run the risk of actually breaking the UI of the page you're looking at - perhaps rendering it unusable. 

July 13, 2011 14:12
User photo
Rich Coleman

#Jake - display plain text (with simple HTML <b> <li> <i>) inside the ZenDesk UI and then click a link to open original email's HTML in a "no-ZenDesk-UI" window/modal.  Problem solved - you're welcome!  =)

July 13, 2011 14:21
User photo
Jake Holman
Product Manager

@Rich: I fear the engineers will laugh me out the room, but I'll suggest it :)

July 13, 2011 14:23
User photo
Hamish Campbell

Or iframe. But I agree with Rich to a point - HTML linting has been around a while so invalid HTML shouldn't be much of a problem.

July 13, 2011 14:26
User photo
Rich Coleman

They must be PHP developers then :)

Could have easily bought you the 3 years of development time it's taken to do it the "non-laughable" way.  :)

July 13, 2011 14:30
User photo
Paul D'Ambra
Rich, actually makes a very important point here. You've had 3 years to implement this. Break it down into steps and get cracking. A gods first step would be to turn any inbound /r/n into a
and to keep any HTML line breaks. I've had two children while waiting for simple WYSIWYG without a single release on this issue!
July 13, 2011 22:53
User photo
Paul D'Ambra

oops s/gods/good/ damn you autocorrect!... also should read "inbound /r/n into a < b r / >"

 

So weirdly the html line break I typed by hand has rendered as such but the line break I entered using the return key hasn't (hint: there was a line break inserted in between "breaks." and "I've"

July 13, 2011 23:48
User photo
community engine

It'd be great for us users to clearly see what the planned date is of features that are marked "Planned". Is there any confirmed delivery date on this functionality?

July 19, 2011 22:40
User photo
Jake Holman
Product Manager

@Community Engine: As I'd said earlier, we're aiming for something this half of the year. We generally don't provide "delivery dates". 

July 20, 2011 19:35
User photo
TJ Baker

Oh just install MarkItUp and implement Markdown and be done with it already:  http://markitup.jaysalvat.com/home/

Ok, just kidding about the order, but I love MarkItUp :)

Thanks for working on getting this feature request implemented Jake et al!

July 21, 2011 23:22
User photo
Jaume Barberena
I am evaluating ZenDesk now, and I really need to have the ability to compose my tickets with html and inline images. Just looks a heck of a lot more professional. I have several hundred sales messages / stock replies stored in 37 Signals Backpack, created with the textile or markdown (I'm not sure which), which I can just copy/paste into Thunderbird. Given how complex it is to have the editor built in to the system - *How about a workaround?* Is there a method existing or which you could create, so we can reply to tickets via Thunderbird or Outlook (just like our clients do) in the cases where we _have to have_ rich text??
August 20, 2011 13:23
User photo
phil starkovich
I don't think this feature is needed. Plain text emails download much faster over my 56k modem while I watch VHS tapes and listen to my 8-track cassette player.
August 20, 2011 18:06
User photo
Gary Lavin
Just one more voice saying that being able to insert Hyperlinks, Bold, paste images etc would make the product perfect
August 27, 2011 17:50
User photo
Lewis Stancer
Qube Tech

I had a ticket from a Customer just the other day who had highlighted some text in yellow.

I had to call him and ask which items we "highlighted below" as our support desk does not render HTML yet and it is something that is being worked on.

This made me look a little foolish don't you think?

+1

September 15, 2011 12:18
User photo
Richard Bysouth
AJB Systems

@Lewis - great point! I can see this happening with some of our customers before long. 

September 16, 2011 01:36
User photo
Andrey Kharuk

Even basic features of text formatting will bring value to Zendesk. I'm with people who vote for the test formatting.

September 28, 2011 18:13
User photo
Nick Jones

Having syntax formatting would be critical for us. We provide support to a national technical computing community, and many of the customer interactions require sharing of code or command syntax, over a private channel (not able to be put up on a wiki page etc).

We also would be expecting JIRA integration, so ensuring that formatting was compatible between systems would be essential.

October 04, 2011 17:55