[Status: Launched 🚀] Code formatting in task descriptions and comments
Could you please enable users to format text in both descriptions and comments as code? Similar to applying the <pre> and <code> HTML tags, any text a user formatted as code would be displayed in a monospace font with long blocks contained within a scrollable element.
Suggested mechanisms for implementation include:
- Dropdown selections in the GUI for code formatting.
- Single tick marks for inline code formatting, e.g., `code`
- Triple tick marks to demark the start/end of a code block, e.g., ```multi-line code block```
Bonus points for:
- Code syntax highlighting.
- Full support of the Markdown syntax.
Hi everyone, I wanted everyone to know that even when we're not commenting here, we see every new comment and have regular discussions with our Product Team about your experiences with this functionality. This is a very important thread to our internal team and we are aware of how many of you want improved functionality and how important it is to your day to day. At the moment, Andrey's last comment is still the most accurate, but he post on this thread early next week to provide more insight and transparency.
Hello, I’m the Product Manager for the comments section and as promised we wanted to give you some more information about this topic. It’s a long post, but please read through to the end, because there is some input from you that would be helpful as we continue the discussion.
Updating the comments section requires two updates on our end:
1) reworking the comment box itself so that it can support formatting options.
2) updating the comment stream so that it can show formatted comments.
The first change is straightforward and fast to implement. Unfortunately, the second update is much more complicated and requires months of a developer’s team time to put into place. It’s something that would take time to do.
As mentioned, we’re currently focusing on improving the functionality within the description field. We chose to start there because the description field is where key task information is stored and this is the reference point for what work needs to be done/has been done.
We’re still in the process of updating the description field and the next functionality we want to work on is the comment stream/box. This development is too far out to share timeframes right now, but we will update you as this changes.
Use Case Data from You
I understand that this is something that a lot of teams are looking for, but it would be helpful to have more feedback so we can understand why this option is so crucial. For code formatting in particular, could you let us know why that type of data would be added in a comment vs. in the description field?
Again, thank you so much for all of your feedback here. As a Product Manager, it’s incredibly valuable to know what you need to see in the product and be able to get input around use cases so that we can plan functionality changes that better meet your needs.
We need the ability to provide more emphatic and varied communication than your simple and antiquated, as your posts admit, interface allows. If nothing else, implementing it will put the pitchforks away and snuff the torches that some of the users here have gathered to use against your team.
When you say things like "the second update is much more complicated and requires months of a developer’s team time to put into place. It’s something that would take time to do." for something that others have been chiming in for nearly a year on, it shows that there has been no emphasis and absolutely no development for clamoring user requests. If you want to destroy your community, this is how best I can think of to do that. If you don't provide the features that users see as basic and necessary, then why implement the voting system in your community at all. It is a real affront to those of us who otherwise would really like to continue using your product for the other features that it provides.
Your byline on the front page of wrike.com states the emphasis of your platform is a communication platform for project management.
For those following along here, it would seem that the features of the big clients (obviously updating the description field and wrike meetings) have much more weight than the requests of the community, which is sad but true always. Money talks. If you represent one of their big clients that have namespace on the website, push through from your position to your wrike sales team to make sure that our voice is heard.
I've gathered a bit from the web on Markdown and hope it is a start to help your teams understand that an inadequate ability to communicate to the team in your platform is a critical flaw that will make teams continue the search, ultimately moving away from your tool, no matter what the other shiny things it can do.
Note I find this is still valid today even after 6 years from post date:
It’s easy: the syntax is so simple you can barely call it “syntax.” If you can use an emoticon, you can write Markdown.
It’s fast: the simple formatting saves a significant amount of time over hand-crafted HTML tags, and is often faster than using a word processor or WYSIWYG editor. It speeds up the workflows of writers of all ilk, from bloggers to novelists.
It’s clean: Markdown translates quickly to perfectly-formed HTML. No missing closing tags, no improperly nested tags, no blocks left without containers. You also get 100% less cruft than exporting HTML from Microsoft Word. There’s no styling inline, nothing that will otherwise break a site’s design or mess with the XSLT formatting for PDF output. In short, it’s foolproof.
It’s portable: your documents are cross-platform by nature. You can edit them in any text-capable application on any operating system. Transporting files requires no zipping or archiving, and the filesize is as small as it can possibly get.
It’s flexible: output your documents to a wide array of formats. Convert to HTML for posting on the web, rich text for sending emails or importing into a layout program for final arrangement or any number of other proprietary formats.
It fits any workflow: You can make Markdown work with any workflow. It can speed up just about any writing-related process with very little setup. It can also be scripted all to hell, if you want, because plain text is the most flexible of any format known to computer-kind."
Implementations of Markdown are available for over a dozen programming languages; in addition, many platforms and frameworks support Markdown. For example, Markdown plugins exist for every major blogging platform.(my emphasis)
While Markdown is a minimal markup language and is easily read and edited with a normal text editor, there are specially designed editors that preview the files with styles, which are available for all major platforms. Many general purpose text and code editors have syntax highlighting plugins for Markdown built into them or available as optional download. Editors may feature a side-by-side preview window or render the code directly in a WYSIWYG fashion.
As we are working in IT development, code formatting is really necessary in comments, as it allows to share and discuss some specific parts of codes with the other followers.
It is mainly highlights of codes (one or 2 lines).
For some types of tickets, especially maintenance or bug reports, the description field only contains the initial request. It wouldn't have any sense to include in the description field anything more (neither text nor code).
Note on the timeline: this is quite disappointing and without a clear due date, I am afraid that this feature will never be added or not before one or 2 years (we only have a first feedback 8 months after the initial post). I hope I'm wrong...
Hi Andrey and thank you for reacting to this.
We really want to be able use one tool to keep track of what we're doing. We are in software development, which means that tasks also has to be able to deal with issues effectively. This will often require referencing code snippets.
Based on the info you have supplied regarding effort for the different stages (description vs. comments), I strongly think the main issue with this would be fixed if just the description would support code formatting.
In a marketing team that focuses heavily on communication between the various team members (copywriting, design, development, management, etc) through various stages of projects, markdown is essential. Being able to properly format comments, even using a basic editor like the one I'm typing this comment into would be a huge improvement. Bullets, indention, bold, etc are absolute musts. I can see how code formatting is just as essential for teams that are more heavily focused on development. Our application development team could never use Wrike as a project management tool because of this.
This is essential, and should top your priority list for development.
You have a months old thread with people getting frustrated and requesting this, and now you are asking them to re-write why this is important? This is ridiculous, and a disappointment.
Description field I think is just self-explanatory. It is a Field to provide a description of the task not to provide updates or comments about the task.
The importance to have markups on the comment section is to highlight statements or important Ideas that require attention. Another benefit of the comment sections is that you have entries with time stamps that way you keep record of who and when was updated while on the Description Field you cannot.
It is sad to hear that there is no Timeline for that feature. Moreover, I am disappointed that there was no response of any Wrike team since May until now.
I feel that this response was only trigger by a message on twitter
Just another thing here, in case you ever get around to making this request happen, please get rid of these dumb ellipses in URLs. This is another failure in the comment editor, the person I posted these URLs to specifically needed full URL, which isn't available yet if the link is clicked as they would land on a preview URL.
What I type/paste into the comment editor should not be truncated in any way.
have you notice that even Reddit has markdown. I have lost faith in Wrike
Can we please have this feature implemented already? Assign an intern or something and review their work, this is not so complicated when there are great libs out there that handle this. Right now Wrike has very limited use for software projects.
Also, why not have a feature vote page where you expose your backlog and let the community prioritise the features for you!
With no need for backend change at all (unless there is something I don't know about your infrastructure).
this seems to be more important
Like we don't have Hangouts, Skype and Slack to cover for this part
To add my 50 cents... There are numerous features that Wrike is missing to be useful in an organisation like mine (IT / Telecoms, £40m/year business, using Wrike primarily for technical network deployments and for software development project management).
We paid a lot of money to Wrike, upfront, for 50 enterprise licenses for 12 months (this was in excess of £30,000) and quickly found that not only were some basic features missing (time lags on dependencies, markdown, simple import/export of projects in various formats), a year of speaking to our account manager and the product development teams yielded exactly zero results. This meant I got exactly £0 worth of value out of Wrike.
As the person that purchases systems on behalf of my company, I can say that I would not be able to recommend Wrike to anyone with any sort of complex requirement - you would be far better off rolling your own or using competitor products.
We have just decided to jump from Wrike to another platform. Following the timeline for this feature and the stuff that Wrike has chosen to focus their resources on just told us that it's not a platform we want to stay on.
At this point, I would recommend anyone to use other platforms, which is sad as Wrike definitely has a lot of potential.
Why is wrike stil putting time in trying to make a skype / hangouts cliënt in wrike while we desperatly need this basic fundamentele feature? This is as driving with no tires on a car with as goal to go on the high way.
Wrike team, please add and priotize this feature !!
This is a fundamental basic feature. So basic that all expected IT to be there. Many more will leave if you do not adress this
One year and still :(
How can a task management system not support code blocks? This is pathetic.
2018 is here and still no code support.
Just today I had a solid example of why it's needed. Copy and pasting output from a terminal into a new Wrike task so a developer can resolve the issue. The description is basically useless without formatting, now he's going to have to copy and paste that and put it in Sublime Text to read it properly, even then it losses some indentation.
This is seriously sad that it's not available; despite all the comments and upvotes. Everything published in the "What's New" section during 2017 is not as important as code formatting in my opinion.
Please deliver on this request. Your product manager should be reading these posts. Any good product manager should already know that code formatting is important, any decent product manager would look at this customer feedback and work with the development team to prioritize this items.
the only time that I got a response from the Wrike team was when I complain about their solution via social media
Hi, I would love to have an update for you, for right now all I can say is that we're sharing your feedback with the Product team regularly. With the holidays and the new year, we're planning on syncing again this month and as soon as we know more from the team we'll share here. We'll provide an update (even just to say that we've discussed things with the team). That said, I want to make sure you know that we're continuing to read every comment on this thread.
@Pedro The social team will of course see your tweets, but this continues to be the best place for feedback and updates related to this topic.
I am sorry @Stephanie Westbrook but It took 1 year for you to answer this topic with no answer how much longer we will need to wait? I do not think that this is the best place to put a feedback. To sell the product we had received one call per day from you guys, but for a needed feature we need to wait more than one year.
New Wrike user here, and we just implemented this for our development / engineering team. I'll spare the long-winded response but add that we could really benefit from this in description and comment inputs. It's absolutely critical for early prototyping on projects and design efforts.
Thanks, and hoping this is going to be added soon.
I'm here to add my support for this request. This constitutes a huge enhancement, and we could begin to entertain the idea of, e.g., unifying our bug tracker within Wrike. Without formatting, attempting this is a non-starter.
Support for monospace, preformatted text would be nice, but markdown support would be better.
why can we have markups in the community forum but not at the workspace?
I know I'm a bit late to the party, relative to your comment back in September, but you asked for case information, and I wanted to supply some.
In our case, the comments would be used by members of the development team to discuss (i.e. a back and forth) about, for example, a software defect being addressed by the task. They would want to include code fragments and back traces for examination or illustration, as well as tabular (plain text) data, which is typically the output of some diagnostic process. Notice that because of the limitations of this text area, I can't just give you examples; instead I can only provide links that require you to at least open a new tab to look at. That the current state of the comment box.
Comments are the place for back and forth conversation about the task. Comments also provide immediate information regarding who made the comment, while you'd have to search through the stream to find that information a the description change.
@Jake Austin - because the community forum was written by the folks over at Zendesk, those guys actually listen to their customers feedback and let their customers drive their CI process. Wrike could learn a thing or two from them...
We are also getting flack from developers who think product is too limited due to lack of this feature. Please help