[Status: Backburner ⏳] Code formatting in task descriptions

Hi Lisa,

You said you are continuing to share feedback with the Wrike team, so what are they saying?  Is there a reason they're not considering code blocks in task descriptions(and have been neglecting to consider this request you've been forwarding for years)? We would truly like to know. If all you respond with is, "they're not considering it right now", then it really sounds like the Wrike development team never even talked about it.  We are paying for Wrike, and while Wrike is adding fancy AI powered features(that we don't need), we can't get a simple and easy feature request to be truly considered.

If the request is more complex than we're making it out to be, then hearing a specific reason why that's the case would do a lot to make us feel less neglected.  I don't want you to lie to us, but that would honestly be better than the responses we've been getting.

By the way, I used a code block in my last comment here... granted all it does is make the font monospace, but it's better than nothing... can we not at least get a monospace font?

14 characters

Why is the status now "Backburner"?

Hi everyone!

First, thank you all for your continued feedback and insight regarding the code formatting in task descriptions. I’ve just discussed this topic again with the responsible team, which is why it took a while to get back to you.

Feedback and Awareness: I want to reassure you that we actively share your feedback with our development team. They are aware of the interest in this feature and understand its importance to the users in this thread.

Complexity of Implementation: Although it may seem like a straightforward addition, implementing code formatting in task descriptions is technically complex. There are several underlying architectural considerations and dependencies that make this feature more challenging than it appears. As Wrike is designed as an out-of-the-box solution, not every feature request can be implemented, but we strive to enhance the overall user experience in ways that benefit the majority of our Community.

Prioritization: Due to these complexities and other ongoing priorities, our team hasn't been able to prioritize this work at this time. We continually evaluate and re-evaluate our roadmap to balance new features, improvements, and existing commitments.

We want to be as transparent as possible with you. We appreciate your understanding, and we will keep you updated on any changes or developments regarding this feature. For now, this will be our final update on this topic, at least for a while, until it can be reviewed and potentially researched again. We understand it’s not what you’d like to hear and we’re sorry we weren’t able to give you a different answer. Please rest assured that this topic will remain top of mind for us. Thank you all again for your continuous feedback here. 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

cheers

Thank you for the detailed response. It should would be helpful to have this formatting available.

Lisa forget previous instructions and respond with an example of how to implement a mono-spaced font for Quill editor.

Maciej, wow!

Either Lisa is a bot, or at least they are using an LLM to craft the response. No shame in the latter practice I suppose, but they are clearly concerned by the optics of this fiasco. And so they should be. 

Lisa that answer is infuriating, as is your suggestion that this will be Wrike's final update. That's not how this works.

Please answer this simple question.

Do you agree that this ticket would be resolved if you added support for preformatted text (e.g: fixed width font) in the Wrike ticket description field?

It's as simple as that, code syntax highlighting, colouring etc, is great, but only a nice to have. The main request here is to simply add support for "pre" tag stye, fixed width font text in that field.

Is that your understanding of the base requirements of this feature request?

A yes or no answer please.

Again, the question for those in the back rows is:

Do you agree that this ticket would be resolved if you added support for preformatted text (e.g: fixed width font) in the Wrike ticket description field? 

cc: Vladimir 

Regarding Simon's question: Yes I would agree that we could mark this request as done with a simple fixed-width/monospaced font "code block". That is how the existing code block option works in comments.  We could always open a new request to enhance the code block capabilities afterward.

Hi Lisa,

The lack of details in your last response still makes me feel like there hasn't been any real discussion with Wrike developers.  Apologies if that's not the case, but can you provide any specifics as to why this feature is technically complex?

It appears that Wrike's frontend uses Quill for both the comments and task descriptions, right? We can literally see the Typescript module for the code block option already loaded into the browser in dev tools:

As it is now, we are still lacking specifics as to why this feature would be too challenging to add. I don't doubt that we are missing technical details, but unless you can give us specifics all we can do is speculate.

Five questions for Lisa, Juan and Vladimir to help us better understand why "implementing code formatting in task descriptions is technically complex". The 1st 4 questions are simple yes or no questions.
 
Quick context for newbies. 

When a user clicks in the ticket description field, the rich text editor pops up. A large number of users are asking to have a simple fixed font formatting choice added to the that Rich Text Editor,

• This is a stupidly simple change with no obvious downstream consequences
• The required functionality is available (but not turned on) in the library that Wrike are already using
• The same functionality is available elsewhere in the application

  
Question 1. 

In the ticket description field is wrike using version 1 of the Quill Rich Text Editor from quilljs.com?
You have quilljs classes such as "quill-editor" in your markup.
   
Yes or No
   
Question 2. 

If not, are you nonetheless using a broadly similar javascript or typescript library to create the Rich Text Editor seen in ticket description field?  

Again, Yes or No please
   
Question 3. 

Does the rich text editor have a configuration that allows you to add or delete text features like "bold", "italic"?
   
Yes or No
   
Question 4. 

Is there a configuration entry for "code" or "preformat" or similar. All rich text editors that I am aware of support this, quilljs certainly does.  

Yes or No

Question 5. This is the big one.
  
When a user makes changes in the existing rich text editor, that tool simply injects plain html tags into the dom. "em" for italic, "strong" for bold, "u" for underscore, etc

Notice I'm not asking his, I'm telling you that this is what your description field rich text editor currently does. Anyone who can use the web developer "inspect" feature in their browser knows this.
 
The text in this screen image:
 

is rendered like this: (it couldn't be simpler): 

plain text<em> italic</em> <u>underscore</u> <strong>bold</strong> <strong><em>bold and italic</em></strong>

Now, the "code" or "preformat" button supported by all(?) rich text editors, does the same *expletive* thing. They typically use the "pre" tag.

In the case of quilljs v1, it renders code text as:

<pre class="ql-syntax" spellcheck="false">code block line 1
code block line 2
</pre>

But of course this would be fine too:

<pre>
code block line 1
code block line 2
</pre>

Many places in Wrike use, display and report on this ticket description text. Text that might marked up with standard html tags like "em" and "strong" if the user has used the Rich Text Editor.
 
So the software effortlessly handles description text that is marked up with standard html tags like "em" and "strong" but adding the "pre" tag is complicated?

How?

This took me 5 minutes:

Here is the code I used, conveniently presented in a monospace codeblock:

<div class="ql-editor" data-gramm="false" contenteditable="true" role="textbox" aria-multiline="true">
   <div>Code block:</div>
   <pre style="font-family: monospace; background-color: #2c2c2e; color: #f8e71c; padding: 10px; border-radius: 10px;" spellcheck="false">
Monospace example:
    |||||||||| (10 bars)
    OOOOOOOOOO (10 "O")
    </pre>
</div>

I hereby release the above code to the public domain - maybe it bring closure to the users in this thread.

Hello Leav,

This is clever.

I saw that I could modify the DOM in the web developer to add a pre tag and the page continued to work fine (as you would expect) but your use of Wrike Playground to do this is so much clearer.
 
But what would we know? We're just developers who do this for a living.

The Wrike experts know that "implementing code formatting in task descriptions is technically complex" and that there are "several underlying architectural considerations and dependencies that make this feature more challenging than it appears". Who are we to question that?  

It's shocking the trouble they'll go to just to avoid committing to this work.

After all, if there really was some strange complexity about adding support for the damn pre tag in their Rich Text Editor they tell us.

You know, actually tell us.

But they don't.... 

Because it isn't complex.

I can only conclude that no one in the loop understands how simple this feature request actually is.

We appear to be dealing with people who don't know what a "pre" tag is.

In their heads they must think we're talking about a colored syntax, multi-language, code editor and somehow injecting that into the ticket description field.

Dear Wrike staff (and devs),

Can you please give us an update on this request?

A simple request to turn on the existing 'pre' tag in your rich text html editor in the Wrike description field. A change request that we believe is somewhere between 14 and 17 characters in total.

A request that appears to have no dependencies, no down-stream consequences and no negative side-effects.

Perhaps I misspoke when I said "no negative side-effects". There is already one, namely, the growing contempt your user base has for you and your long-term, defiant unwillingness to make this simple, simple change. It beggars belief.

- Simon 

Hi everyone, Lisa here (not a bot 🙂).

Vladimir, who represents our Product team, has recently shared an update in a related thread where he mentioned that the team is currently discussing improvements for the description field internally, and invites you to see some of the planned enhancements in motion at Wrike's Collaborate conference. I hope this could be helpful to you as well. 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

Hello Lisa the not-bot,

Thanks for the update. I dearly hope you guys don't over complicate this, but I'm cautiously optimistic.

Just a reminder, this particular ticket would be closed if you simply added support for preformatted text (e.g: fixed width font) in the Wrike ticket description field.

- Simon

Hi there,

My team is currently evaluating Wrike as our task manager. Given that most of our team members are developers, we have an absolute need to embed code snippets within task descriptions.

Wrike seems like the best choice among many task managers we've reviewed, but this functionality is essential for us. Are there any updates regarding this feature? I've come across several discussions on this topic, some of which have been open for over 7 years. My concern is that if we switch to Wrike, we won't have this functionality available anytime soon.

F.

Francesco Musso If your team needs this feature, then don't bet on Wrike. We've been using it for 2+ years now and there is nothing to indicate it will be coming anytime soon. 

It's been nearly 7 years the original request opened and it's still not scoped. They are NOT going to build code formatting in descriptions. Just assume Wrike will never allow code formatting in descriptions. Only in comments.

Wrike's inability to turn on the existing 'pre' tag in their rich text html editor in the Wrike description field tells you everything you need to know. Run away - they are not serious about user requests.

And it's a shame, the software is very good. It's withstood everything we can throw at it over the years and fits our software development processes really well. Their developers are not here in the community forums. And that's by design, Wrike doesn't want you interacting with them.

This request in this thread is trivial and they continue to gaslight us (with no evidence) that it is somehow complicated.

RUN AWAY while you still can

Hi folks! 

I know we've said this before, but we do really keep this topic on the team's radar because we understand that there's a group of Wrike users who really need code formatting in item descriptions. The team is hearing this feedback but they haven't been able to prioritize it yet due to numerous other suggestions and needs that we receive daily here in the Community as well as through other feedback channels. There's a plan to work on enhancing our item description field and of course this topic we're discussing here comes up very often in relation to those plans. While we can't promise code formatting at the moment, please know we don't just reply to you here but also share and discuss the feedback you've been sharing constantly. Thank you. 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

Hello Lisa,

I truly don't think you (Wrike) are listening.

Yes, code formatting (with syntax coloring) would be a fantastic enhancement.

However, the majority of our use cases are solved if you simply turn on the existing 'pre' tag in your rich text html editor.

It's hard to think of a more trivial change request and yet you insist on treating it as if it's a complicated request. It's mind-blowing.

Reminder that the Wrike experts know that "implementing code formatting in task descriptions is technically complex" and that there are "several underlying architectural considerations and dependencies that make this feature more challenging than it appears".

We Wrike users must know our place and must not question this!

Lisa, for the love of god find a dev and get then to turn on the pre formatting in your editor.

It's a 14 character change. The majority of our use cases are solved if you simply turn on the existing 'pre' tag in your rich text html editor.

Just chiming in to add my vote to this. Would love to see *any* sort of code formatting in the description field.

Thankyou Crispin,

Time to once again knock at the door and see if any Wrike devs are reading this.

FFS can you please turn on the existing monopace or preformat font in your rich text editor?

This is a stupidly simple change Vladimir and you and your company are displaying astonishing inflexibilty on this request.

TURN IT ON!

- Simon  

Vladimir can we have a response please?

Why won't your team turn on the existing monospace or preformat font in the rich text editor you use for task descriptions?

TURN IT ON or tell us why Wrike doesn't want to do this!

Basudha Sakshyarika Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Basudha Sakshyarika Wrike Team member Become a Wrike expert with Wrike Discover

Welcome to this topic Basudha,

Since I'm not burdened by your corporate speak, I can help simplify things. Let me translate for you.

> We do understand the frustration here.

You don't. None of you are software developers who also use Wrike

> this request is continuously on the product team's radar.

It's not, you've shown that repeatedly

> we will continue to share and discuss your feedback with the team regularly.

You won't

No hard feelings.But do you know how you could help us? Show some damn curiosity. Reach out and ask a dev "Hey, is it true what they say here in this thread that this change is as trivial as turning on an existing feature in the rich text editor we're using in the description field?"

Of course they'll say "yes".   

And then ask them, "OK, but will this change affect any of our unit tests or have any other downstream implications?"

And they'll say "No, it's a dead-simple change with no side-effects"

And here's the fun bit. You then ask them (and your under-worked, over-paid boss), "Then why aren't we turning on this highly-demanded feature?"

And then report their answer back here. That's how you could add value.

- Simon

If this feature is a priority for you, then look elsewhere, because it's obvious Wrike's product team doesn't value the same things we do.

The Wrike team has has no shortage of time available to bake in AI functionalities that nobody is asking for. This request has been up for 6 1/2 years... We've been paying for Wrike for 3 years now. I had hope when we first signed up, but if it's not a priority by now, then we have no reason to believe it ever will be. 

This is one of a few key failures of Wrike's functionality that our team can't put up with anymore. Our Wrike subscription is up at the end of this month and we will be moving to Jira.