We wanted to give an update on the rollout of Rich Text which we began general availability to partners starting January 10th, 2023. After an Open Early Access for Rich Text where we made improvements based on feedback, we took a cautious approach to the rollout of Rich Text by deploying the feature in waves to our customer base rather than all at once. On the second wave of rollouts (targeting approximately 30% of customers overall), we became aware of some specific scenarios impacting a subset of accounts with Rich Text.
Rather than continue with the rollout, we have decided to pause while we investigate and mitigate these issues. Our engineering team is working to address these issues and we will be deploying fixes as they become available. We will continue to keep our Known Issues Board up to date and will update our Release Notes with deployed fixes. Thank you for your continued support and feedback.
Iâll say that the biggest issues for us were simple:
-Our workflow involves typing a note, pushing âtabâ, (changing labor type if necessary), pushing âtabâ, typing in âminutesâ (15, 45, whatever), Return.
The tabbing was fully impossible with rich text, requiring mouse touches for every time entered, instead of being able to keyboard it. It feels like Rich Text should be a checkbox we can enable or disable in the Admin area.
-The second issue was simply that it was impossible to read or look at when using Dark Mode (virtually all of us use Dark mode). The issue seems obvious - that Rich Text ascribes a âtext colorâ to the text, and if itâs not white (or if itâs black), we wonât be able to see it in dark mode. Thereâs no function for inverting the colors.
Edit - also, none of these were listed in the âKnown Issuesâ area that we found so Iâm just pointing out that these seemed wildly obvious to us, but it must be that others arenât using these basic functions of tabbing and dark mode. (other tab issues are noted but NOT the simple workflow issue when entering time via the Notes area on a ticket)
While I once agreed with you, once the HTML is exposed, itâs permanent, so if you disabled it after, all your tickets would be a mess. There might be a fix for that, but this was what happened when it first released and was pulled and no fix was released. Iâd like this to be an opt-in with a warning that itâs permanent.
We use dark mode and have hardly any issues. There are occasionally where it comes through as dark on dark, but Iâve sent those in and hopefully they can prevent that.
There were quite a few bugs I reported that didnât make it onto the board. The board is new, so Iâm giving them some room on getting their processes refined. Iâm sure thereâs some procures a bug has to go through before itâs considered âknownâ. I didnât use tab prior, so I didnât discover any tab issues during my testing. Tab is a valid function for RTF, so I donât know what a solution would be for bringing back the previous function.
Of all the good I see with the new editor, this is my biggest change to my flow. Im a fast typist and being able to bang out a ticket with hotkeys was nice. Id be okay with an alt code to get to time like alt+t or something to break out of the editor so we can tab to complete the ticket. Perhaps that might be something to look at.
Here, here. I definitely want the focus on fixing whatâs broke, as itâs hobbling our operation at present, but being able to hop out of the text field with a hotkey would help me get back to my old flow.
The most frustrating part is the particular problem we had instantly when this got turned on the first time is still outstanding. On 8/17 I contacted support, Syncro disabled Rich Text and the case was closed by support hours later, my assumption was Syncro was going to pull all support cases related to Rich Text and evaluate this as they went forward after reverting the feature the first time around.
Got it. In all honesty once the ticket communication piece is perfect, weâll likely look at adding it to canned responses next, and then potentially other areas of the platform based on current priorities.
While I once agreed with you, once the HTML is exposed, itâs permanent, so if you disabled it after, all your tickets would be a mess. There might be a fix for that, but this was what happened when it first released and was pulled and no fix was released. Iâd like this to be an opt-in with a warning that itâs permanent.
Agreed on this being an opt-in, which is the âcheckboxâ I mean. I donât care if itâs a one-way checkbox (canât un-check it later on), thatâs fine. But give me the option!
But even so - thatâs not necessarily a problem - they can implement rich text everywhere, and just disable or enable it for ânew ticketsâ. Thereâs nothing preventing it from not displaying on old ones.
Even a tickbox to use it in general for any given ticket. They can wrap it all around a span or div or p or whatever they want.
Itâs 2023. You donât have to have it one way or the other. They can all be ârich textâ as long as the user inputting it doesnât have any options that are stealing the âtabâ key from them or forcing them into a font color (which was what was happening - the font was âblackâ in CSS and therefore in dark mode wouldnât be visible).
Then, that doesnât prevent the user from just typing in notes , tab, tab, 30 (minutes), tab, spacebar (to charge), return (to create the public note and charge it). Boom - workflow saved.
When they first released it and then pulled it, all tickets that came in during that time had HTML left behind on them and they became a mess. Thatâs what I was speaking to specifically. The old tickets were not affected. They didnât have anything in place to hide all of that once they pulled it. They may have fixed it with this release since there is an opt out option if you write into support.
